New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HubConnection.Stop takes 30 seconds on Silverlight client #3102
Comments
Thanks, we'll take a look. If you can share any more information that may help us to reproduce the issue please do so. |
Even though we send Abort request it is actually never sent by the HttpClient when using the portable HttpClient library. The 30 seconds is the default timeout we wait for the response to the Abort request. Until I find out why the underlying HttpClient never sends the Abort request you can use the |
It looks that even though the SignalR client invokes
|
This is because of a deadlock. We block the thread waiting for the response to the abort request to the server. If the thread we are blocking happens to be the UI thread it will cause a dead lock since Silverlight wants to send the request on the UI thread. |
@yowl - one way to work around this issue is to invoke .Stop on a non-UI thread - e.g.: |
Fixing #3067 will "fix" this issue. |
"Fixed" in 7358f1d - we no longer block to receive a response to abort request. |
We had to revert the change since it introduced a couple of issues and races we were able to identify and possibly some we have not hit. It became apparent that the change is too risky. We will need to re-think the transport-connection interaction to fix this correctly and/or make the Stop call async. |
We'll look at this for v3 |
I attempt to close the SignalR connection before the users logs out of my silverlight client using this code and it takes 30 seconds to do so. I saw #2191 and maybe the fix for the .net client is not applied to the SIlverlight client?
Stop code which takes 30 seconds - this is not called from within an On method..
The text was updated successfully, but these errors were encountered: