Clarification sought of object/class hierarchy for Gatling custom protocol

Gatling (Open-Source)
1

Hi,

Does anyone have a good reference / specification that explains the relationships between all the Factories/Builders/Classes/Objects needed for a custom protocol in Gatling?

I am trying to implement something, and use the JMS protocol as one of the example implementations, but I get lost trying to understand how the ProtocolBuilder/Protocol/RequestBuilder/ReqReplyActionBuilder/ReqReplyAction/Message/MessageMatcher/RequestTrackerActor interact between themselves and with the Gatling actor system.

What exactly is expected to be made available to Gatling so one can use a custom protocol. Which interfaces/classes do I need to supply, what actor behaviour should be implemented?

My usecase: perform load tests on a central server cluster (3 to 9 servers) that is connected to by a large group of clients (100 to 500) that make permanent connections (TCP) and execute multiple queries (1 to 20 per minute per client)

I have seen http://gatling.io/docs/1.5.6/developing_gatling/implementing_your_own_protocol_support.html, but that is for an old version; page has disappeared from later Gatling specs.

Are we no longer supposed to attempt adding custom protocols, and use Gatling for HTTP testing only?

Regards,

Jean-Marc.

P.S.: I have also seen http://mintbeans.com/load-testing-zeromq-with-gatling/, but the explanation given there assumes one already understands the Gatling internals. And it is based on 2.2.0-M3 and mapping/translating it for 2.1.7 is left as an exercise for the reader. According to the page, it uses a connect-query-terminate for each invocation instead of connect once per client/user/session and execute a multitude of queries during the scenario execution.

2

Hi,

Basically, those are internals, not a public API.
Until we decide to turn them into a public API, we want to be able to change them without further notice.
Providing a public API means a lot of extra work and constraints: documenting, answering questions, providing migration paths, etc.

For example, we’re changing them in 2.2.0, and I suspect that implementing HTTP/2 support for 2.3 will force us to come up again with a different design.

However, once HTTP/2 support will be stable, we’ll probably be able to provide a public API.

So far, people who have been able to implement custom protocol supports have been doing so on their own, they just dug into our code.

Some of them decided at some point to generously contribute their work to Gatling.
We then take care of maintaining.
This is what happened for JMS and WebSocket support.

If you’re looking for inspiration, you can have a look at all the third parties listed in our documentation. Maybe the TCP one could help you.

Then, there’s also the possibility of your company contracting with us to get this implemented, either open-source, or closed source.

Regards,