We’ve implemented SSE in our solution and it’s been working great in our test environment. We’ve also tried it on test cloud servers to see how it would perform with ‘slower’ network connections.
We’ve come to setup our solution at a client’s site and we’ve had feedback that the system wasn’t updating correctly. On investigation, it appears that the browser attempts to connect to the event-stream, hangs for a while and then returns around 200-300k of data with a 200 status code and then loses the connection. It then attempts to reconnect but gets subscription ID not found messages and stops receiving any data.
To rule out a problem in our code I attempted to connect to the ServiceStack example chat client (http://chat.servicestack.net/) and that behaved exactly the same.
Any ideas? My gut feeling is a network proxy or firewall that’s mangling and/or buffering the data which is causes problems.
It’s not through an ASP.NET Web App it’s self hosted so I don’t think the compression will be the issue.
I’ll give the buffering and chunked-encoding a go, however I can’t seem to find the correct information regarding how to turn off buffering and chunked encoding. I’ve added the following to my globalresponsefilter:
Dim originalResponse As System.Web.HttpResponse = res.OriginalResponse
originalResponse.BufferOutput = False
It should be disabled at the HTTP Proxy if you’re going through one. You’re saying you can see the same behavior with http://chat.servicestack.net ? Is it showing that it’s disconnecting and re-connecting in the UI? If so I suspect you’re going through a HTTP Proxy or something else that’s terminating long-lived HTTP Connections.
If you’re hosting with a HttpListener Self-Host you wont have ASP.NET buffering issues. I’ve not seen any buffering issues with HttpListener. Are you using the latest v4.0.46?
Are the clients accessing the HttpListener directly or going through another web server / reverse proxy?
Otherwise there might be another issue, it’s strange that the subscription ID no longer exists unless its terminated by the client or no heartbeats were not getting through to keep connection alive. Can you post the raw HTTP Headers showing the connection failures and 404 subscription errors (using something like WebInspector / Fiddler).
Yeah, same behaviour at chat.servicestack.net. It doesn’t show anything when you first visit, then after a delay the information (names, etc) appear and it says connected and error at the same time.
Using the latest v4.0.46 and self-hosting.
Sadly it’ll be very hard to get more data since we can’t install software on this machine. I’m only going from the native Firefox console errors. I’ll see what I can get.
How much delay do you mean? What do I have to do to see the error, just leave it running?
I’ve left http://chat.servicestack.net running in Firefox for the last 40mins and hit it with 600+ requests and have yet to see a failed HTTP Request. It’s not disconnected once, both letting it sit idle (just sending auto heartbeats) and hammering it with multiple commands.
Unless you have steps I can take to repro, I’m going to assume the error is local to your network. I’d look at performing an analysis on the failed requests, if it’s due to TCP connection’s being dropped you may have to consult your System Admin as to why that is. You can try running an instance of Chat within your Intranet to see if you can localize which network has the issue, i.e. if it fails connecting to another PC in the same subnet, or a remote server in a different subnet.