History for SignalR/src
Commits on Dec 12, 2014
This reverts commit 654bfb4.
Commits on Dec 4, 2014
Commits on Dec 2, 2014
Commits on Nov 21, 2014
Commits on Nov 6, 2014
…e server AspNetWebsocket uncoditionally throws a NotSupportedException from the Dispose() method, so #ifdefing the invocation so that we only call Dispose on the client.
Commits on Oct 31, 2014
Commits on Oct 30, 2014
Commits on Oct 29, 2014
Commits on Oct 24, 2014
… transport If an exception happened while reading a message using the websocket store transport we would not handle. As a result it would be bubbled up and would crash the user's app. The user have no way of catching this exception. The fix is to catch exceptions and report them to the user using the IConnection.Error and to close the websocket to enable reconnect logic. Workitem #3313
Commits on Oct 15, 2014
- In the event of any transport error prior to the init message, the transport should immediately stop and allow the connection to fall back to another transport. - In the event of any transport error during the start request, the entire connection should immediately be stopped
Commits on Oct 10, 2014
Commits on Oct 1, 2014
- DefaultDependencyResolver will now no longer retain instances to IDisposables that implement the special marker interface IUntrackedDisposable. #3208
Commits on Sep 23, 2014
Since we serialize the invocations of Received callbacks in the .NET client, there is a real risk of deadlocks resulting from one callback blocking waiting on another callback to execute. This commit introduces a TaskQueueMonitor used exclusively by the .NET client to try to detect callbacks that are running long and notify the user using Connection.OnError that a callback may be deadlocked. The amount of time a callback may execute before an error is raised can be configured using Connection.DeadlockErrorTimeout. The default timeout is 10 seconds. #3167
Previously the store `WebSocketTransport` would accept `Send` requests when the transport was reconnecting. The change to invoke `OnError()` and throw an exception if this happens - similarly to what we do in the .NET Client.
The store WebSocketTransport did not respect the disconnect token. Now if the disconnect cancellation token is cancelled we will not try to reconnect if the websocket gets closed and if we are already trying to reconnect we will stop doing this. Note that we don't need to register to the cancellation event since the disconnect cancellation token is cancelled only in the `Connection.Disconnect()` method which also disposes the transport which will take care of the all needed clean up. Also fixed a race in the WebSocketTransport.Dispose method which might lead to unwanted reconnection attempts. Workitem #3189
Commits on Sep 19, 2014
- This should prevent ObjectDisposedExceptions from WindowsIdentity in OnDisconnected
- Adds support for instance names passed in by Katana v3+ (currently Katana v3+ breaks perf counters in SignalR) - Tweaked how instance name is set internally in PerformanceCounterManager to make it testable without affecting the public contract - Updated the sample project to use Katana v3 to ensure we get coverage of fix - #3002
Commits on Sep 16, 2014
`ServerSentEventsTransport` and `LongPollingTransport` registered callbacks to let the `TransportInitializationHandler` know that the transport failed (by calling the `TransportFailed` method) when the `disconnectToken` is tripped . This was unnecessary since the `TransportInitializationHandler` registered first its own callback for the same reason which would call `TransportInitializationHandler.Fail()`. Because we use the `SafeThreadInvoker` for invoking the `Fail()` method the calls from the transport implementations were no-ops because they would have happened after the call from the `TransportInitializationHandler` which in turn would make `SafeThreadInvoker` ignore any further calls.
…request If a transport failed during the start request or if the start request failed we would not fail the transport or throw an exception leaving the transport in kind of a zombie state. The reason for this was that we used `SafeThreadInvoker` to start the start request which invalidated any further `Fail` calls. When AutoTransport was being used we would always try the next transport even though the correct behavior was to throw from the `Start` method if the connect request completed successfully and a failure occured during start request. The fix is to not to use SafeThreadInvoker to start the start request. In addition we have to track the state of the initialization phase to prevent failing the transport due to timeout once the connect request completed successfully and to throw the StartException after connect request completed successfully to let the AutoTransport know to not try the next available transport but to re-throw the exception. Workitem: 3227
Commits on Sep 12, 2014
…ansportBase Removing references to TransportInitializationHandler from transport implementations since initialization is now handled in the ClientTransportBase class. Types derived from the `ClientTransportBase` can now override the OnStartFailed protected method to be notified if/when a failure occurs during starting the transport and can invoke the `TransportFailed` method if a transport specific error occurred to notify the `ClientTransportBase` about the error.
Commits on Sep 11, 2014
All client transports have to follow the same start pattern where they have to override the OnStarted method instead of the Start method.
Commits on Sep 9, 2014
Commits on Sep 8, 2014
Updating references to Microsoft.Net.Http NuGet package to fix build errors appearing when building a Xamarin Android project after adding the Signalr Client NuGet package to the project.
Commits on Sep 6, 2014
Commits on Sep 5, 2014