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?.
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.
I dont have much details... I always do the same thing: this.Connection.Start() and rarely this bug occurs.
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.
Moving to post 1.0 RTW
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
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.