Force shut down a client, server execution flow didn't go into IDisconnect.Disconnect () at all #511

Closed
imkow opened this Issue Jul 5, 2012 · 1 comment

3 participants

@imkow

Environment:
a self host server, client is Win8 WinRT app, all 0.5.2, Json.NET 4.5.7, all on Windows 8 Release Preview build 8400.

The same problem when the self host server on Windows Server 2008 R2, client is WinRT app as well.

Repo steps:
client connects server (Hub), does some stuff, and force close the client from Task Manager.

server doesn't detect (server code execution flow doesn't go into IDisconnect.Disconnect()), even after a long time

UPDATE:

RegisterForDisconect never get called, weird

even client called HubConnection.Stop() got server side IDisconnecet.Disconnect() called, no break at RegisterForDisconnect()

@davidfowl davidfowl was assigned Jul 8, 2012
@davidfowl
SignalR member

This is indeed a bug with the self host implementation and longpolling. We'll fix this for 0.5.3

@NTaylorMullen NTaylorMullen was assigned Aug 3, 2012
@NTaylorMullen NTaylorMullen added a commit that referenced this issue Aug 3, 2012
@NTaylorMullen NTaylorMullen Fixed #511 and memory leak for self hosting
The #511 fix was being caused by LongPolling never
RegisteringForDisconnect.  This was because the invocation was being
called in the DoWriteAsync method iwthin the HttpListenerResponseWrapper
when LongPolling only uses the DoWrite piece.  Moving the invocation to
the DoWrite Segment (aka the catch all for writes) fixed the issue.

The Memory leak resulted from multiple requests being called and each
registering for disconnects.  For instance, if using LongPolling
transport and user sends 100 messages there was be 102 disconnect
callbacks, 100 for the messages and 2 for the 2 connection streams.
This was fixed by re-doing how the cancellation token process was built.
Added CancellationTokenResolver whos responsibility is to manage a 1 to
1 relationship between cancellation tokens and connection id's instead
of a 1 to many.
32bde20
@NTaylorMullen NTaylorMullen added a commit that closed this issue Aug 3, 2012
@NTaylorMullen NTaylorMullen Fixed #511 and memory leak for self hosting
The #511 fix was being caused by LongPolling never
RegisteringForDisconnect.  This was because the invocation was being
called in the DoWriteAsync method iwthin the HttpListenerResponseWrapper
when LongPolling only uses the DoWrite piece.  Moving the invocation to
the DoWrite Segment (aka the catch all for writes) fixed the issue.

The Memory leak resulted from multiple requests being called and each
registering for disconnects.  For instance, if using LongPolling
transport and user sends 100 messages there was be 102 disconnect
callbacks, 100 for the messages and 2 for the 2 connection streams.
This was fixed by re-doing how the cancellation token process was built.
Added CancellationTokenResolver whos responsibility is to manage a 1 to
1 relationship between cancellation tokens and connection id's instead
of a 1 to many.
0693d92
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment