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
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.
I’d say that… it depends
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.
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.
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
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
Anyway, great idea for MongoDb and the random content for feeders Your feedback is really appreciated
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.
I wonder if this community is interested in this MQTT support?
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?
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(connect)
.insertChain(chain.exec(subscribe(“Subscribing to the MQTT server”, “sample topic”)))
.insertChain(chain.exec(disconnect(“Disconnect from the MQTT server”)))"
),
