Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Closed
imkow opened this Issue · 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
@davidfowl
Owner

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

@NTaylorMullen NTaylorMullen referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@NTaylorMullen NTaylorMullen was assigned
@NTaylorMullen NTaylorMullen referenced this issue from a commit
@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 closed this issue from a commit
@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
Something went wrong with that request. Please try again.