We had an issue with that and had to change it manually. In our case, the application send a jSessionId even if the user is not authenticated. A new one is sent when the user authenticate and it wasn't took by Gatling so we were always "unauthenticated".

Actually, the first SET COOKIE was took without any problem by Gatling, but not the second one

Thanks you!

I'd previously asked about this an in issue filed against the gatling jenkins plugin project.

It would be awesome if the Gatling jenkins plugin could find and archive multiple gatling reports from an individual jenkins build run, and graph them against one another in the trend graphs. It appears that the trend graph widget already supports this, so it seems doable.

I started poking at the source code to see about submitting a pull request for this. I found a pretty easy path forward as far as locating multiple reports after a build, making sure they are relevant to the current run, and archiving them. However, it looks the next necessary step might be to change the definition of GatlingBuildAction such that it supports an array of simulations rather than an individual one. Before I go too much farther down that path I was hoping to get a general sanity check to make sure that:

1. that sounds correct, and
2. you guys are interested in this idea and would be willing to consider merging something along these lines once all of the kinks are worked out.

Thoughts?

Some people run very short scenarios, even 1 request scenarios as their application is a service, like REST API.

In this case, they are more interested in the rate of requests per second than the number of users.

We could have a second API, along the current user oriented one, that would let the users configure user launch rate.

Let's be clear that the real number of requests per sec would depend on the time it takes for a user to complete the scenario.

Here's what I have in mind:

scn.configure.startUsersAtRate(numberOfUsersStartedSec)
                   .holdFor(duration)
                   .rampTo(numberOfUsersStartedSec, rampDuration) // rampDuration is optional and defaults to 0
                   .holdFor(duration)
                   ...

WDYT?

Hello, I try to load test our new CAS authentication server with SPNEGO, but I can hardly write the scenario.

I disabled followRedirect, cause it wouldn't really reauthenticate at replay. The recorder record Cookie value, but if I replay the scenario, it only succeed the life time of my CAS Ticket.

A header looks like : "Cookie" -> """JSESSIONID=DYNAMICALY_GENERATED; CASTGC=DYNAMICALY_GENERATED_BY_CAS

I wonder what is the good way to handle the Cookie value ? I tried :

• to remove the Cookie in the Header, hoping that Gatling would reinject received Cookie : KO
• to remove CASTGC key and value in the Cookie : KO

Reading issues, I am not sure it is possible to capture a cookie value in order to reinject it.

Any advice on a good way to handle this scenario ? Thanks, Fabien.

I've been brought up to believe that whenever you fix a bug, you should add a test for it, so it doesn't re-surface. I didn't include a test with issue #1845, because it was hard to test at a component level, and that's been bothering me.

This patch includes a test for #1845 (in HttpIntegrationSpec). It uses WireMock to simulate a system-under-test, and initialises just enough of Gatling to test it. There's also a re-usable support class, to enable this integrated style of testing.

I can't decide if this is a good approach or not. More testing's good, but it's adding complexity.

Thoughts?

The environment Gatling 3.5.1. Win10. Running from gradle plugin. I have tried from Windows CMD and Git Bash.

The steps

1. Clone example gradle plugin demo https://github.com/gatling/gatling-gradle-plugin-demo.
2. Run it first time with commands that are show in readme.
3. When finished run second time.

The problem When running second time I only get and tests don't start.

BUILD SUCCESSFUL in 1s
4 actionable tasks: 4 up-to-date

When I run gatlingRun command with clean, like this gradlew clean gatlingRun, then it starts tests again. But this also deletes results from build folder.

It appears that iOS is picky about what certs it trusts.

the gatling cert is not trusted on iOS devices, this blocks proxying https through the recorder on iOS devices.

related ref: http://blog.httpwatch.com/2013/12/12/five-tips-for-using-self-signed-ssl-certificates-with-ios/

the charles cert worked ok

Scala 2.13 is now feature-frozen and the ecosystem has started porting to 2.13.

It would be great if Gatling 3 were able to run on Scala 2.13 as well.

Hi,

I have been running tests at a fairly high request rate: 'rampUsersPerSec(10) to(900) during(30 minutes) randomized'

and eventually receive the below exception.

12:30:42.333 [ERROR] i.g.h.f.ResourceFetcher - Actor ResourceFetcher crashed on message None java.lang.IndexOutOfBoundsException: null at java.nio.CharBuffer.wrap(CharBuffer.java:371) ~[na:1.7.0_65] at jodd.lagarto.Scanner.charSequence(Scanner.java:128) ~[jodd-lagarto-3.6.jar:3.6] at jodd.lagarto.LagartoParser.emitScript(LagartoParser.java:2896) ~[jodd-lagarto-3.6.jar:3.6] at jodd.lagarto.LagartoParser$46.parse(LagartoParser.java:1981) ~[jodd-lagarto-3.6.jar:3.6] at jodd.lagarto.LagartoParser.parse(LagartoParser.java:114) ~[jodd-lagarto-3.6.jar:3.6] at io.gatling.http.fetch.HtmlParser.parseHtml(HtmlParser.scala:192) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.fetch.HtmlParser.getEmbeddedResources(HtmlParser.scala:198) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.fetch.ResourceFetcher$.inferredResourcesRequests$1(ResourceFetcher.scala:83) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.fetch.ResourceFetcher$.inferPageResources(ResourceFetcher.scala:107) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.fetch.ResourceFetcher$.resourceFetcherForFetchedPage(ResourceFetcher.scala:178) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.ahc.AsyncHandlerActor.executeNext(AsyncHandlerActor.scala:158) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.ahc.AsyncHandlerActor.logAndExecuteNext(AsyncHandlerActor.scala:181) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.ahc.AsyncHandlerActor.io$gatling$http$ahc$AsyncHandlerActor$$ko(AsyncHandlerActor.scala:185) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at io.gatling.http.ahc.AsyncHandlerActor$$anonfun$receive$1.applyOrElse(AsyncHandlerActor.scala:87) ~[gatling-http-2.0.0-RC5.jar:2.0.0-RC5] at akka.actor.Actor$class.aroundReceive(Actor.scala:465) ~[akka-actor_2.10-2.3.6.jar:na] at io.gatling.core.akka.BaseActor.aroundReceive(BaseActor.scala:23) ~[gatling-core-2.0.0-RC5.jar:2.0.0-RC5] at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516) ~[akka-actor_2.10-2.3.6.jar:na] at akka.actor.ActorCell.invoke(ActorCell.scala:487) ~[akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238) ~[akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.Mailbox.run(Mailbox.scala:220) ~[akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393) [akka-actor_2.10-2.3.6.jar:na] at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) [scala-library.jar:na]

Simulation finished. Simulation successful. Reported by @hgomez

• Gatling 1.4.7
• Jenkins plugin 1.0.2

Generating reports... Reports generated in 4s. Please open the following file : /d2d/var/lib/mycorp/cijenka/builder5/workspace/artifactory-perfs-testing-200-users-direct/results/csvinjector-20130502101332/index.html ERROR: Publisher com.excilys.ebi.gatling.jenkins.GatlingPublisher aborted due to exception java.lang.NumberFormatException: For input string: "csvinjector" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:410) at java.lang.Long.parseLong(Long.java:468) at com.excilys.ebi.gatling.jenkins.GatlingPublisher.getTimestampFromFolderName(GatlingPublisher.java:172) at com.excilys.ebi.gatling.jenkins.GatlingPublisher.findLastReportTimeStamp(GatlingPublisher.java:163) at com.excilys.ebi.gatling.jenkins.GatlingPublisher.perform(GatlingPublisher.java:66) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733) at hudson.model.Run.execute(Run.java:1593) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) Finished: FAILURE

I know that throttling (pacing) is still up for debate in the bug list, but it's the one feature I need to get buyoff on conversion from JMeter. I am nearly there building it myself for a single test case, using ResponseInfoExtractor to count the responses, and a ListBuffer to keep track of timestamps, which get filtered to age out timestamps older than a second on every invocation of the extractor.

It works great, but the only thing missing is dynamically changing pause times. If the generateDelayInMillis() function was exposed in the builder, it would allow dynamic rate limiting, as well as open up a lot of potential for custom-built pause variations. Is it possible to get this exposed in the builder to allow for custom and dynamic pause definitions?

As mentioned in Issue: https://github.com/gatling/gatling/issues/4371

Acctual version of InfluxDB Telegraph is 1.24 but Documentation refer to 1.20:

https://github.com/gatling/gatling/blob/b4e431758e775a3887bf54d41b2758e9116b49d6/src/docs/content/guides/realtime_monitoring/index.md?plain=1#L59

I wondering if it will be better to set version to latest: https://docs.influxdata.com/telegraf/latest/data_formats/input/graphite/

Acctual version of InfluxDB Telegraph is 1.24 but Documentation refer to 1.20:

https://github.com/gatling/gatling/blob/b4e431758e775a3887bf54d41b2758e9116b49d6/src/docs/content/guides/realtime_monitoring/index.md?plain=1#L59

I wondering if it will be better to set version to latest: https://docs.influxdata.com/telegraf/latest/data_formats/input/graphite/

As kotlin is now the standard for plugin for gradle, we should rewrite our plugin.

Pros:

• will naturally solve issue with kotlin gradle configuration #4337
• will use a typed language (more close to scala we know how to use)

Cons:

• we don't know kotlin either
• will have to dig in gradle documentation
• time consuming

Requirements:

• Current user groovy gradle configuration should still work (except for the plugin version itself, obviously)

Gatling: 3.8.3 (gatling-charts-highcharts-bundle-3.8.3) OS: Windows 10 Pro JDK: jdk-17.0.4

Will be nice if will be only Error Message without Stack Trace when provided not valid Token: