Server Events Client - Race Condition?

Thanks for all your help mythz, I’m first going to just disable events client completely and publish and see if the CPU issue still occurs, if so, then it isn’t related, but if the CPU issue disappears, then I’ll do more investigating and report back.

1 Like

OK so after removing Events Client (commenting out the connect part) - we have yet to have CPU go above 1% so there is definitely a CPU issues here tied to the ServerEventsClient. Normally we would see the CPU start inching up after about 2mins, but it’s still stuck at 0%

I guess the next step is to try 5.8.1

Hey mythz - let me ask you something - should we be dispatching any Handlers to a new thread? Is it possible that a long running data handler on the ServerEventsClient could cause issues?

The callback is invoked in the WebRequest async callback thread, if you need to execute a long running operation you should run in a different background thread.

If this is being called from a Server you can use the Background MQ Service to publish messages and have them executed on a managed background thread.

I just wanted to follow up here so that you would know the resolution.

We had to stop using Server Events client on our web apps. We continued to battle unpredictable server CPU spikes with 5.8.1 in an Azure environment. There seemed to be some correlation between when we would do an App Service swap and the spikes, but there was no predictable way to know what was causing them and then all of the sudden, one of our client web apps would spike up to 80-95% CPU with profiler showing being Reconnect in the Server Events Client.

We moved to an HTTP callback method where the server calls back to the client via HTTP requests instead of via ServerEvents and things have been stable since.

I really wish I knew why ServerEvents was so unstable because it gives me concern for uses in the future, but maybe it wasn’t designed for long lived connections.