Tidied up some comments, to make the ResetPing client behavior easier to understand.
Will ping in debug mode for consistency. If this becomes a problem when debugging, developers can disable the pings manually. It's easier to fix something noisy, than try to diagnose inconsistently missing behavior.
- Log from inside of HubConnectionContext if the user callback failed.
- Use ThreadPool.QUWI instead of Task.Factory.StartNew.
- Remove try catch from HubConnectionHandler
* Simplify error handling in HubConnectionHandler
- Since we execute hub methods inline, there's no need to abort the connection on unexpected exceptions.
- Don't pass the cancellation token to ReadAsync, instead just use CancelPendingRead.
- Don't treat OperationCancelledException errors as errors.
- These are the finishing touches before we disable batching on the
C# client and on the server. We're changing the IHubProtocol interface to
modify the input buffer with what was consumed. We're also changing it
to parse a single message at a time to be match what output writing does.
- Added TryParseResponseMessage and made it look like TryParseRequestMessage
- React to rename of EndPoint to ConnectionHandler
- Rename UseSockets to UseConnections
- Rename MapEndPoint to MapConnectionHandler
- Rename HttpSocketOptions to HttpConnectionOptions
- Made HubCallerContext an abstract class
- Made DefaultHubCallerContext that gets data from the HubConnectionContext.
- Removed IP address
- Removed Connection property
- Don't allocate when enumerating connections
- Don't allocate tasks unless we truly go async
- Don't get the timestamp, just write the pings always (if there's no ongoing write)
- Track the time since last keep alive write instead of the last write
- ValueTask all the things!
- Renamed HubConnectionList to HubConnectionStore
* 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
BrennanConroy
Dylan Dmitri Gray
Mikael Mengistu
Andrew Stanton-Nurse
James Newton-King
David Fowler
Ben Adams