Advice on handling and recording Server Side Events (SSE) data sent over long-lived HTTP connections.

Hi there,

I’m very new to Gatling so bear with me. I have an app which uses Javascript to invoke a “server-sent events” (SSE) request. This is basically a normal HTTP request for a response with Content-Type “text/event-stream” which stays open and sends data back as a partial body response whenever an event is triggered on the server-side. So far I have used Gatling successfully to make this kind of request with the right headers, and used ResponseInfoExtractor to show that the event data is indeed received intact during the simulation.

Here are my questions.

  1. ResponseInfoExtractor only gets triggered when the response is completed, which in my case only happens when I force a timeout on the client-side (using requestTimeoutInMs in gatling.conf or similar). I would like to see the data as it arrives for testing and to capture the time it was received. Is this possible by overriding GatlingAsyncHandler.onBodyPartReceived( … )? If so how could this be configured? Will I need to change the Gatling source code itself?

  2. When I try using Gatling Recorder as a proxy the SSE request fails to establish a connection properly, and the events don’t get through. So the app is broken even though the rest of the app loads and the requests for all other HTML files, images, js etc are detected and picked up by the Gatling Recorder. However when I redeploy the Tomcat app all the SSE requests that were previously sent suddenly do appear in the Gatling recorder, as if they were piling up and being flushed on a redeploy. What could be going on here? More importantly - is there any way I can set up the Gatling recorder to successfully make this kind of connection and pass through event data so that app works fully, and still record these kinds of SSE requests being sent?

Any advice would be very gratefully received :slight_smile:

Best wishes,


Making it short: we don’t currently support SSE, sorry.
Regarding the Recorder, it’s based on complete responses, so I’m not surprised it doesn’t work.
Regarding the engine, overriding GatlingAsyncHandler.onBodyPartReceived would suffice: Gatling HTTP expects complete response to proceed to the next step, and maybe put the connection back into a pool. This use case really requires a proper dedicated support.

There’s a thread on Twitter that might be interesting for you: