SignalR .NET Client HubConnection looping between Reconnecting and Connected #1121

Closed
EduC88 opened this Issue Dec 11, 2012 · 6 comments

Projects

None yet

6 participants

@EduC88
EduC88 commented Dec 11, 2012

Hi,
I could not reproduce the bug, but sometimes my client's (WinrRT app) HubConnection enters in a loop of state changing between Reconnnecting and Connected (almost 3 seconds between changes). It this a known bug of the SignalR 0.5.1.10822 for WinRT version?.

Regards,
Eduardo

@davidfowl
Member

when does it enter the loop? I'm not aware of any issues like that using the older version of the client. We've made changes in later versions but I don't know if it fixes the issue. We really can't do much without more details.

@EduC88
EduC88 commented Dec 11, 2012

I dont have much details... I always do the same thing: this.Connection.Start() and rarely this bug occurs.

@mbaynton

Just caught something that looks very similar to this because I happened to have Fiddler up. I'm not sure how the client reported the connection state, but Fiddler showed an apparently endless cycle of /?transport=serverSentEvents / /?transport=longPolling. I was on the .net 4 client. Cursory attempt at reproduction didn't succeed, but I'll keep trying.

fiddlerscreen

@rustd rustd was assigned Dec 18, 2012
@DamianEdwards
Member

Moving to post 1.0 RTW

@davidfowl davidfowl was assigned Feb 21, 2013
@davidfowl
Member

Turns out this has nothing to do with WinRT.

When the timout exception occurs nothing prevents the SSE source from
starting allowing multiple conenctions to the server from the same .NET
client to infinitely reconnect.

The AutoTransport.ResolveTransport gets the timeout and proceeds with
Long Polling even though the server will eventually come back and
successfully start the SSE source. Multiple connections to the server
will cause the Long Polling to get kicked off trigger a reconnect which
endlessly cycles through the two connection types and the client
reconnects infinitely.

  • This was described in #910.
  • This generally happens on client using .NET4.0 and below where
    WebSockets is not available.
  • Two seconds also seems a bit short and increasing the value to 5
    seconds makes this far less likely to occur.
  • Checking a token ensures that SSE will not be enabled when a
    TimeoutException has already been raised faulting the task created by
    AutoTransport.
  • This issue can be reproduced by creating a delay (Fiddler) in the
    response to connect?transport=serverSentEvents.
@davidfowl davidfowl added a commit that referenced this issue Feb 21, 2013
@davidfowl davidfowl Fix fallback from sse to longpolling to avoid infinite request loop.
- Abort the SSE request when timing it out.
- Updated tests to detect this condition.
- Updated MemoryHost to throw OperationCancelledException to mimic iis.

#1121
e069dec
@davidfowl davidfowl added a commit that referenced this issue Feb 21, 2013
@davidfowl davidfowl Fix fallback from sse to longpolling to avoid infinite request loop.
- Abort the SSE request when timing it out.
- Updated tests to detect this condition.
- Updated MemoryHost to throw OperationCancelledException to mimic iis.

#1121
0a6ff14
@Xiaohongt
Member

verified

@Xiaohongt Xiaohongt closed this Feb 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment