We use ServerEventsFeature in our application for sending notifications to clients. First day the application went live we found that IIS stopped working after some time with HTTP 503.2 since number of parallel requests exceeded max of 5000. Looking into IIS running requests list I found that all requests were for event-stream. Further checks showed that when client closes event source, the request on IIS continue to run, so even there were about 60 clients, IIS got stuck with 5000 requests.
The problem was fixed (bypassed?) by adding RemoveExpiredSubscriptions into response filter.
Is SSE supposed to be used in this way? I did not see mentioning of this in ServiceStack doc.
If not, how it is supposed to work?
No plain EventSource is not sufficient, you need a client that also sends heartbeats (i.e. any of the clients provided) so the server knows to keep the connection alive and can perform the necessary house-keeping.
I don’t understand the question. If it’s do you need to use an SS Server Events Client like I’ve listed above? Yes, you should.
Technically you don’t need to if you manually handle sending heartbeats and calling unregister URL when disconnecting, retry on failed connections/heartbeat failures etc. The provided clients transparently handles these book keeping details and makes handling Server Events much easier to work with. Whist not using the clients is what’s causing the undefined behavior you’re seeing which need to be manually configured to handle the book keeping tasks the existing Server Events client are already configured to handle.
Please read through my answers very carefully so I’m not having to keep repeating myself.
You absolutely need a Server Events client that sends heartbeats, Server Events wont function properly if it doesn’t send heartbeats. This entire thread is because you’re using a client that doesn’t send heartbeats. You can send heartbeats by using any of the clients I’ve linked to above. In addition to sending heartbeats each clients automatically connect/retry when it detects an event-stream no longer exists. If you don’t use any of the existing clients you’ll be using an unsupported configuration that will continue to have issues until it’s configured to send heartbeats. You can look at the source code of ss-utils to see the code we use to configure and send periodic heartbeats.
We changed our client implementation and using now ss-utils.js.
Mainly it work but we still have a problem with lost notifications after IISRESET. Client does not reconnect automatically to the channel and notifications sent after IISEREST do not reach clients until they relogin.
That’s not the behavior we’re seeing which auto reconnects after receiving a failed heartbeat. The clients aren’t going to receive any messages whilst they’re reconnecting (i.e. when they’re not connected), but they should auto reconnect. You can test this on the Chat Server Events Example App.
Make sure your heartbeats are working and when you do an IIS Reset the clients are sending/receiving a failed heartbeat.