Call for feedback: Documentation

Hi Gatling users!

I’m working on the documentation for next version of Gatling (1.1). To know where I should focus, I’d like to have feedback from our (currently little) community.

I plan to document the plugin APIs to help developers create plugins for Gatling:

  • Checks API (Add new checks to gatling)

  • Request API (Add support for other protocols)

  • Feeder API (Add new sources and consuming strategies for feeders)

  • Chart API (Make charts with another library than highcharts) ← I think this is not urgent so it may not be finished for 1.1. If you need it, please let me know.

This is what I think I should do right now. If you need anything else concerning documentation, please ask :slight_smile:


That seems like a good idea to me. What form do you see plugins
taking? Are you expecting stand-alone projects that add the necessary
plugins or fork the main code base and make a pull request? I could
easily whip up a few additional plugins so a general guide as to how
you guys want those integrated with the main project would be great.


Hi Chris,

I’d say that… it depends 328.png
The best way is to ask us on the mailing list.

What I think :

  • A plugin can be integrated into the main project if it’s compatible with Apache 2 licence. It might then be a new module like gatling-http (for example, another protocol like JDBC, JMS, AMQP, etc…) or be part of an existing protocol support (for example, providing protobuf support over http).
  • If it’s not compatible with Apache 2 (like gatling-vtd), it has to be hosted into a dedicated project, and the master has to be on the Excilys github account to be an official plugin we can provide support for.



2012/2/15 Chris Carrier <>

Makes total sense. The only plugin I’ve thought of that uses external dependencies would be a MongoDB feeder. That would depend on the Casbah Scala driver for Mongo which is licensed under Apache2. Otherwise I think some utility feeders like random numbers, random strings, random emails etc could fill out the toolkit a bit and would be simple to implement and not require any license stuff at all.



Hi Chris (& Stephane :slight_smile: ),

I’d say that there two other factors that could influence the choice:

  • Plugin weight
  • Expected use by users
    What I mean is that if a plugin requires many libraries (or heavy ones) the tarball weight overhead could be discussed here :slight_smile:

Also, if a plugin is really specific to a particular use case, having it in the main bundle could be useless, therefore, a plugin could be required.

I’m thinking that, on our website, we could (later of course) list all available plugins, their licenses and the people behind. I prefer, as Stéphane, to discuss the plugins on the group before deciding if we would include it in the bundle :slight_smile:

Anyway, great idea for MongoDb and the random content for feeders :slight_smile: Your feedback is really appreciated :wink:




I am developing a MQTT support to Gatling now. I learned how to do this plugin by reading the gatling-http project.
I certainly do need the good documentation on Request and Checks API.

MQTT’s request model is very different from HTTP, thus the current DSL reads pretty ugly. :frowning:

I wonder if this community is interested in this MQTT support?

Hi Richard,

Sounds interesting.

Beware that we’re breaking quite a few things in the underlying API in the upcoming 1.1.
Do you build your DSL on top of the master (1.1) or the 1.0 maintenance branch?
I’d be very interested in your feedback on how our APIs can be easily extended.
Can we talk about it next week?



2012/2/17 Richard Chuo <>

Hello Stéphane,

I am building my DSL on top of the master (1.1).

The reason why the DSL looks ugly is partly because I have to keep the MQTT client for a user in this user’s session for the next request.
For example, after a user connects to the MQTT broker, I need this same MQTT client to send say a subscription message (message type: SUBSCRIBE) to the broker.
The connection session must be maintained along the whole scenario.
Therefore a sample scenario would be:

“val connect = chain.exec(mqtt(“Connect to the MQTT server.”) connect(“localhost”, 1883, ABC3467S”) check(connAck.eq(MqttMsgType.CONNACK.toString)))
val connScenario = scenario(“Connect to the MQTT server.”)
.insertChain(chain.exec(subscribe(“Subscribing to the MQTT server”, “sample topic”)))
.insertChain(chain.exec(disconnect(“Disconnect from the MQTT server”)))"

I think there is is a small issue in the documentation : "Dynamic values
with Feeders" :

/* Scenario */

Must be

Hi Paul,

Fixed, thanks!

2012/2/19 Paul Langeard <>

Hi Richard,

One of the guys in our company uses MQTT and could be interested.
He’s very busy right now but will contact you probably next week.



2012/2/17 Richard Chuo <>

Cool! We are working on a large-scaled project based on MQTT. This is why I try to add MQTT support to the great Gatling framework. :slight_smile: