* Remove the Channel<HubMessage> from the HubConnectionContext
- Replace the channel with a single lock around the pipewriter. Since writes are always synchronous, the lock is held for a very short time.
- We were only using them in this scenario for handling multiple producers (the hub output, the keep alive ping and the broadcast).
- Handle the scenario where there's back pressure (when we use pipes that are bounded) and give callers a single task representing when back pressure is released.
- Handle synchronous exceptions in RedisHubLifetimeManager
- Fixed benchmarks
When the client cancels a streaming method the server would send an error completion. This was not correct because cancellation is not an error. We did not see this because our client ignores any messages for a given streaming invocation after sending a CancelInvokationMessage but other clients may want to drain messages before considering a streaming method canceled.
Late parameter binding
Storing exception thrown during parameter binding and rethrowing when the method is about to throw. This allows completing invocations with a HubException and keeping the connection open.
We will also no longer close the connection if parameters for client side methods cannot be bound. We will log and continue.
Fixes: #818
(Also fixing #1005 because I was just touching this line)
* fix issue with incorrect user detection when Invoking for User
* fix failed testcases
* use proper extension method to avoid potential null reference exception
* fix for channel name in redis version + follow SignalR team recommendations
* remove unncessary freespace
* remove whitespaces
* introduce IUserIdProvider to resolve user id
* Move IUserIdProvider from HubLifetimeManager to HubConnectionContext
* setting user id to connection context in hubendpoint
* Remove the params argument from IClientProxy
- This allows passing arrays without having to explicitly ToArray() or AsEnumerable()
- Added overloads up to 10 arguments
- Added tests
We need to close the connection if there is an exception when writing to the transport on the server side. Currently if an exception happens it leaves the connection in an unsable state - after the exception no messages from the server will be sent to the client because the writing loop is terminated. Ignoring the message could cause hangs on the client side since we can fail while writing a completion message. In this case if the client is awaiting the invocation it will hang because the task will never be completed.
* Added Cancellation support
- Added ConnectionAbortedToken to the HubConnectionContext. This allows
arbitrary code to access a handle that represents the connection lifetime
without handling OnDisconnectedAsync on the hub itself.
- Expose Abort on HubConnectionContext to allow server side methods to
abort the connection.
- Use the Abort to stop the main loop when unexpected invocation errors happen.
- Use the connection aborted token as unsubscribe from the IObservable and to complete
the IAsyncEnumerator for streaming results.
James Newton-King
Mikael Mengistu
BrennanConroy
Andrew Stanton-Nurse
David Fowler
Pawel Kadluczka
Nate McMaster
Pawel Kadluczka
Gurgen Hakobyan
ivankarpey
moozzyk
FTWinston