Gatling never ends

[Jeff MAURY]

Hello,

I'm running a Gatling simu on Jenkins/Cloudbees.

Depending on the tested server, the simulation never ends and no more requests are processed.

Is there a way to run in parralel of the simulation a control job that could stop Gatling if there is no activity detected or after a timeout ?

Thanks

Jeff

[Stéphane Landelle]

Hi,

Which version do you use?

--
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.

[Jeff MAURY]

2.0.0-M3a

--
You received this message because you are subscribed to a topic in the Google Groups "Gatling User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gatling/HaBjawCsRtg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gatling+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

[Stéphane Landelle]

Would you mind upgrading to current snapshot, that probably solves your issue.

I can help you migrating and refrain from committing until your talk is over.

WDYT?

[Jeff MAURY]

The maven project is at https://github.com/devoxx2014-webperf/moviebuddytests, I suppose we must add the snaphot repo and change the Gatling version ?

I can add you as a commiter, this is for Devoxx and we are in a hurry

[Stéphane Landelle]

The maven project is at https://github.com/devoxx2014-webperf/moviebuddytests, I suppose we must add the snaphot repo and change the Gatling version ?

I can add you as a commiter,

Or I can fork and send a PR, as you wish

 

this is for Devoxx and we are in a hurry

Yep, I know :)

[Jeff MAURY]

Let's do both if we need further modifications

--

You received this message because you are subscribed to a topic in the Google Groups "Gatling User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gatling/HaBjawCsRtg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stéphane Landelle]

OK.

I've just sent a PR.

Let me know if it solves your problem.

Documentation is under way here: https://github.com/excilys/gatling/tree/master/src/sphinx

--

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.

[Jeff MAURY]

It got better but:

 Gatling fail at the end processing the simulation log file classcastexception

I got many 304 return codes but it maybe because of the node server

I'm out of home and won't be online until 9pm Paris time

Jeff

—
Sent from Mailbox for iPhone

[Stéphane Landelle]

2014-04-12 16:00 GMT+02:00 Jeff MAURY <jeff...@gmail.com>:

It got better but:

 Gatling fail at the end processing the simulation log file classcastexception

We had a tricky situation with Travis.

I've just restarted the build for gatling-highcharts, it's fine now. Please update your snapshot (-U from maven)

 

I got many 304 return codes but it maybe because of the node server

Probably yes. You get 304 because the page wasn't modified since.

 

I'm out of home and won't be online until 9pm Paris time

Ping me if you have any problem/question.

[Jeff MAURY]

Is there a way to prevent the use of cache or last modified ? Is this new to Gatling as I didn't notice this for 2.0.0-m3a

—
Sent from Mailbox for iPhone

[Nicolas Rémond]

Yup, it's been introduced after the 2-M3a

You can use .disableCache for what you want, cf : https://github.com/excilys/gatling/blob/master/gatling-http/src/test/scala/io/gatling/http/HttpCompileTest.scala#L46 

[Stéphane Landelle]

More precisely, what was introduced since 2M3a is Last-Modified and ETag support.

Before that, we were only supporting Cache-Control.

[Jeff MAURY]

Hello,

I have fixed the 304 status code with the settings you recommended.

However, I still have the error at the end of the simulation.

I join the console from Jenkins.

Jeff

[Stéphane Landelle]

100% sure that your snapshot isn't up-to-date (gatling and gatling-highcharts are not aligned). You can see it in your logs (only metadatas were downloaded)

Did you run with -U to force maven to update snapshots as I suggested?

One more thing, there's an ugly stacktrace in your logs:

java.lang.NullPointerException

at com.ning.http.client.providers.netty.timeout.TimeoutsHolder.cancel(TimeoutsHolder.java:27)

at com.ning.http.client.providers.netty.timeout.IdleConnectionTimeoutTimerTask.run(IdleConnectionTimeoutTimerTask.java:66)

at io.gatling.http.ahc.AkkaNettyTimer$$anonfun$1.apply$mcV$sp(AkkaNettyTimer.scala:41)

at akka.actor.Scheduler$$anon$11.run(Scheduler.scala:118)

at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:39)

at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:385)

at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)

at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)

at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

This is a bug in AsyncHttpClient I'll try to fix ASAP.

[Stéphane Landelle]

I've fixed the AHC bug and released 1.8.7. Just waiting for the jars to get synced on central so I can update Gatling too.

[Stéphane Landelle]

AHC 1.8.7 deployed on central, just pushed upgrade on Gatling: https://github.com/excilys/gatling/issues/1797

New snapshot will be available on Sonatype once Travis job is complete: https://travis-ci.org/excilys/gatling

[Jeff MAURY]

Hello,

yes, I have added the -U flag. See the following lines from the console:

gatling-node-cluster (AllMoviesLoading)] $ mvn -U test io.gatling:gatling-maven-plugin:2.0.0-SNAPSHOT:execute -Dgatling.loops=100 -Dgatling.resultsFolder=results -Dgatling.simulationClass=com.jeffmaury.moviebuddy.tests.AllMoviesLoadingScenario -Dbuddyserver=http://movie-buddy-node-cluster.devoxxfr-web-perfs.cloudbees.net

I will retry this morning to check if AHC 1.8.7 is downloaded.

Regards

Jeff

[Stéphane Landelle]

yes, I have added the -U flag. See the following lines from the console:

gatling-node-cluster (AllMoviesLoading)] $ mvn -U test io.gatling:gatling-maven-plugin:2.0.0-SNAPSHOT:execute -Dgatling.loops=100 -Dgatling.resultsFolder=results -Dgatling.simulationClass=com.jeffmaury.moviebuddy.tests.AllMoviesLoadingScenario -Dbuddyserver=http://movie-buddy-node-cluster.devoxxfr-web-perfs.cloudbees.net

You're right, you did set -U.

Still, it doesn't make sense that snapshots weren't re-downloaded?!

[Jeff MAURY]

Yes i've seen but looking at the remote repository (https://oss.sonatype.org/content/repositories/snapshots/io/gatling/highcharts/gatling-charts-highcharts/2.0.0-SNAPSHOT/ for example), it sees there is something broken in the deploy as the maven-metadata.xml is less recent that the artifacts !!!!

Jeff

[Stéphane Landelle]

You're right, metadatas are not up-to-date, no idea where it comes from for now, investigating.

Until we find out, could you just remove the gatling directory from your Jenkins local repo?

--

[Jeff MAURY]

I'm using the Cloudbess jenkins so I don't know how to do it. The sole solution I see is to use a per job Maven repository

--
You received this message because you are subscribed to a topic in the Google Groups "Gatling User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gatling/HaBjawCsRtg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gatling+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stéphane Landelle]

My2cents: snapshot metadatas are not computed on publish, but are batched computed once a day. Current metadata pretends that last update is 20140412131623, ie yesterday.

[Jeff MAURY]

Yes, I sought it was computed as part of the deploy phase. I'm running the job with the prive repository option so it should download every artifacts. Waiting for the job to complete.

Jeff

[Stéphane Landelle]

I thought so to.

We'll open an issue on Sonatype to find out.

[Stéphane Landelle]

https://docs.sonatype.com/display/SPRTNXOSS/Nexus+FAQ#NexusFAQ-Q.The"latest"and"release"tagsinmaven-metadata.xmlarenotbeingupdatedafterdeployingartifacts

Actually, this is not a bug but expected behavior.

If -U doesn't force update, that's probably a Jenkins/Cloudbees issue.

[Stéphane Landelle]

Could you try setting updatePolicy to always in your pom, please?

<updatePolicy>always</updatePolicy>

[Jeff MAURY]

I need to focus on my tests now as I more than late for friday !!!

Anyway, I don't think this will fix the issue as the metadata.xml is not uptodate.

Jeff

[Stéphane Landelle]

Read the FAQ: maven isn't supposed to use them the way you think.

[Stéphane Landelle]

Maven should use repository metadatas to determine if snapshot is supposed to be updated.

[Stéphane Landelle]

shouldn't

[Jeff MAURY]

Maybe a problem with the Maven version available at Cloudbees ?

Jeff

[Stéphane Landelle]

Maybe.

Or maybe that Cloudbees proxifies maven central into it's own maven repository, and there's a cache expiration delay that's too high for snapshots.

If you're still stuck by next week, maybe I could temporarily host a timestamped version on a private repository.

[Jeff MAURY]

No, I'm ok now with the private Maven repo per job.

Jeff

[Stéphane Landelle]

Glad to hear!