Feed results of one scenario into subsequent scenarios

[Jonathan Ben-Ami]

I'm quite stumped on some side-effects that seem to happen from trying to write to a file from within a scenario. I'm using PrintWriter to try to take the results of one scenario to write to a csv, which I want to read in subsequent scenarios. The file does get written and from proxying network traffic I can even see the the next scenarios start running. However, gatling ends the simulation, shows the other scenarios at 100% without any results for them, and displays the following error:

...

Simulation finished

16:44:17.378 [DEBUG] c.n.h.c.p.n.r.NettyConnectListener - Trying to recover from failing to connect channel [id: 0xeeb2ff74] with a retry value of false

16:44:17.378 [DEBUG] c.n.h.c.p.n.r.NettyConnectListener - Failed to recover from connect exception: java.nio.channels.ClosedChannelException with channel [id: 0xeeb2ff74]

16:44:17.379 [DEBUG] i.g.h.a.AsyncHandler - Request 'find' failed for user 4242294551669458470-4

java.nio.channels.ClosedChannelException: null

        ... 17 common frames omitted

Wrapped by: java.net.ConnectException: http://135.128.17.5:80

        at com.ning.http.client.providers.netty.request.NettyConnectListener.onFutureFailure(NettyConnectListener.java:128) [async-http-client-1.9.18.jar:na]

        at com.ning.http.client.providers.netty.request.NettyConnectListener.operationComplete(NettyConnectListener.java:140) [async-http-client-1.9.18.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:409) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:400) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:362) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$1.operationComplete(NioClientSocketPipelineSink.java:115) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:409) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:395) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:340) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.AbstractChannel$ChannelCloseFuture.setClosed(AbstractChannel.java:455) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.AbstractChannel.setClosed(AbstractChannel.java:194) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioChannel.setClosed(AbstractNioChannel.java:168) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioSocketChannel.setClosed(NioSocketChannel.java:84) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:356) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientBoss.close(NioClientBoss.java:169) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:325) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.1.Final.jar:na]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.8.0_40]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.8.0_40]

        at java.lang.Thread.run(Unknown Source) [na:1.8.0_40]

16:44:17.383 [DEBUG] c.n.h.c.p.n.f.NettyResponseFuture - asyncHandler.onThrowable

java.lang.UnsupportedOperationException: AsyncHandlerActor pool hasn't been started

        at io.gatling.http.ahc.AsyncHandlerActor$.instance(AsyncHandlerActor.scala:58) ~[gatling-http-2.1.5.jar:2.1.5]

        at io.gatling.http.ahc.AsyncHandler.sendOnThrowable(AsyncHandler.scala:122) ~[gatling-http-2.1.5.jar:2.1.5]

        at io.gatling.http.ahc.AsyncHandler.onThrowable(AsyncHandler.scala:107) ~[gatling-http-2.1.5.jar:2.1.5]

        at com.ning.http.client.providers.netty.future.NettyResponseFuture.abort(NettyResponseFuture.java:238) ~[async-http-client-1.9.18.jar:na]

        at com.ning.http.client.providers.netty.request.NettyConnectListener.onFutureFailure(NettyConnectListener.java:132) [async-http-client-1.9.18.jar:na]

        at com.ning.http.client.providers.netty.request.NettyConnectListener.operationComplete(NettyConnectListener.java:140) [async-http-client-1.9.18.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:409) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:400) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:362) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$1.operationComplete(NioClientSocketPipelineSink.java:115) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:409) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:395) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:340) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.AbstractChannel$ChannelCloseFuture.setClosed(AbstractChannel.java:455) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.AbstractChannel.setClosed(AbstractChannel.java:194) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioChannel.setClosed(AbstractNioChannel.java:168) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioSocketChannel.setClosed(NioSocketChannel.java:84) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:356) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientBoss.close(NioClientBoss.java:169) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:325) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.1.Final.jar:na]

        at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.1.Final.jar:na]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.8.0_40]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.8.0_40]

        at java.lang.Thread.run(Unknown Source) [na:1.8.0_40]

Without the print writer the code everything works fine. I'm not really sure how to progress from here. Am I trying to do something that isn't supported? My code looks something like this (don't worry if it doesn't compile):

val setup = repeat(3) {
    exec { session => session.setAll("tenantId" -> Uuid.newUuid, "username" -> "joesmith") }
    .exec(
      Foo.doSomeBar1,
      Foo.doSomeBar2,
      Foo.Etc)
    .exec(update(_)) // saves intermediary data for later
  }
  .exec(save(_)) // writes all the data to file


def save(session: Session): Session = {
    val writer = new PrintWriter(resourcesPath.resolve("global.csv").toString)
    val data = get(session)


    data  foreach { x => writer.write(s"\r\n${x._2("someId")},${x._2("accessToken")}") }
    writer.close()


    session
  }

which is called something like this (don't worry if it doesn't compile):

class Tests extends ServiceSimulation
{
 val axisPoints = new Axes("setup" -> 1) // this is my rendez-vous points configuration (using counters)
 val setup = scenario("setup")
    .exec(Setup.setup)
    .exec(session => {
      axisPoints.increment("setup") // ups the counter so that the following scenarios can run
      session})


    setUp(
    setup.inject(atOnceUsers(1)),
    run(getScenario, "setup",
      nothingFor(1),
      constantUsersPerSec(activeLoad) during(duration seconds)), // this is just a wrapper that waits for the "setup" rendez vous point counter before starting getScenario
    run(searchOrder, "setup",
      nothingFor(8),
      constantUsersPerSec(searchLoad) during(duration seconds)) // this is just a wrapper that waits for the "setup" rendez vous point counter before starting searchScenario
  )
    .protocols(httpProtocol)
}

There's lots of code that I'm not posting but I'm not sure what (if anything) is relevant.

Any help appreciated, thanks,

Joni

[Stéphane LANDELLE]

Any chance you actually have a maxDuration configured?

Then, I'm afraid this is impossible to investigate without a reproducer. Note that those are DEBUG logs.

Stéphane Landelle

Lead developer

slan...@gatling.io

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

[Jonathan Ben-Ami]

Goodness, I feel silly. Yes the max duration was cutting it off :)

I had it on for backup in case a thread gets stuck (happens rarely not sure why), before I started adding loops in my scenarios.

Thanks!

[Stéphane LANDELLE]

That's good news :)

What happens is that maxDuration kind of kills the run and shut down resources. But some events can't still be in the IO threads and about to be processed, hence the possible DEBUG crashes and dead letters. I'm not sure how we could have a graceful shutdown, and that's not really a priority, as it just causes some weird DEBUG logs.

Cheers,

Stéphane Landelle

Lead developer

slan...@gatling.io

[Jonathan Ben-Ami]

I agree it's not a priority, it's only that I was actually stumped on this for a long time. If it was possible to add a debug or warning log that mentioned that max-duration might cause strange behavior, it might help understand the other errors in the log. Just a suggestion, I'm glad you thought of it immediately even though I didn't even post it in the code :)