Version of com.ning async-http-client to use with Gatling 2.0?

143 views
Skip to first unread message

sfos...@twilio.com

unread,
Sep 2, 2015, 1:12:12 PM9/2/15
to Gatling User Group
Using Gatling 2.0 because I'm adding it to an existing scala 2.10 project.  Unfortunately, we reference an older version of the com.ning async-http-client, and the version used by gatling does not seem to be backward compatible with it.  So, I have to explicitly reference this library, and no matter what version I reference, at some point I get a NoClassDefFoundError:

According to this, the version with which Gatling was compiled is 1.9.0-BETA21 (yikes!).

Here are the errors I get with each reference:

1.9.0-BETA21: NoClassDefFoundError: com/ning/http/client/PerHostConnectionPoolPartitioning
at io.gatling.http.ahc.ChannelPoolPartitioning.getPartitionId(ChannelPoolPartitioning.scala:30) - gets farther than any other version
1.9.0, 1.9.1:  NoClassDefFoundError: com/ning/http/client/date/TimeConverter at io.gatling.http.ahc.HttpEngine$.start(HttpEngine.scala:96)
1.9.3:  NoClassDefFoundError: com/ning/http/client/date/TimeConverter at io.gatling.http.ahc.HttpEngine$.start(HttpEngine.scala:96)

What version should I be referencing?

Stéphane LANDELLE

unread,
Sep 2, 2015, 2:44:06 PM9/2/15
to gat...@googlegroups.com
Have a look at the AsyncHttpClient commit log and you'll realize that for about 2 years now, AHC has been driven by me, i.e. Gatling.

Regarding the BETA version, that's simply because when Gatling 2.0 was released, AHC 1.9 API wasn't stable enough to cut a stable release for general usage.

Other projects that depend on AHC (such as Play! and Dispatch) are bound to lag behind Gatling in terms of AHC version. Play! is doing a great job at keeping up the pace, but it means that you have to keep your project up-to-date too.

Gatling has many dependencies, and we can't afford to try and keep a compatibility with whatever stack around, and all the more with YOUR stack we don't know anything about (and that would be Professional Services).

If you have complex dependency conflicts, the best way is to not mix Gatling and your project, and keep Gatling in its own module/project with its own dependency tree.


Stéphane Landelle
Lead developer


--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

sfos...@twilio.com

unread,
Sep 2, 2015, 2:50:27 PM9/2/15
to Gatling User Group
Thanks, Stéphane - yeah, I definitely wouldn't be looking for it to be compatible with our stuff, which is why I was trying to take ours out of the loop entirely and override our version with an explicit reference.  So, I was just looking for the correct version to reference.

Stéphane LANDELLE

unread,
Sep 2, 2015, 2:54:28 PM9/2/15
to gat...@googlegroups.com
I don't think that's possible. If this Gatling version depends on a BETA version, it probably means it's not compatible with anything else.
AHC and all the more Netty are widespread in the Scala world, and the compatibility matrix mess is just the beginning.
I can promise you some fun when Netty 4.1 will be out...

Stéphane Landelle
Lead developer


Reply all
Reply to author
Forward
0 new messages