Skip to content
This repository

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

Closed
imkow opened this Issue July 05, 2012 · 1 comment

3 participants

imkow David Fowler N. Taylor Mullen
imkow
imkow commented July 05, 2012

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()

David Fowler
Owner

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

N. Taylor Mullen NTaylorMullen referenced this issue from a commit August 01, 2012
Commit has since been removed from the repository and is no longer available.
N. Taylor Mullen NTaylorMullen referenced this issue from a commit August 03, 2012
N. Taylor Mullen 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
N. Taylor Mullen NTaylorMullen closed this issue from a commit August 01, 2012
N. Taylor Mullen 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
N. Taylor Mullen NTaylorMullen closed this in 0693d92 August 03, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.