Gatling 2.0.0-M3a to 2.0-SNAPSHOT migration

Gatling (Open-Source)
1

Hello,

Where I can find the list of changes that expected in M3b or M4a?

Already I found some surprises, just wanted to have an eye on them.
What I see is:

  • CONF_CORE_TIMEOUT_ACTOR - this setting is eliminated, and I cannot find quick replacement of this. (I use custom non-http actions, and this timeout was pretty useful)
  • DataWriter.tell is now implemented in trait DataWriterClient by writeRequestData
  • many more errors in compilation. And want to migrate my code as robust as possible.

Do you have some quick “change log” of backward incompatible changes and suggestions how to cope with them?

Thanks in advance,
Dmytro

2

Hello,

Where I can find the list of changes that expected in M3b or M4a?

Already I found some surprises, just wanted to have an eye on them.
What I see is:
- CONF_CORE_TIMEOUT_ACTOR - this setting is eliminated, and I cannot find
quick replacement of this. (I use custom non-http actions, and this timeout
was pretty useful)

Most actors are shared and not related to a given request, so it didn't
make sense to time them out before timing out the simulation.

If you spawn one actor instance per request, you then have to define your
own. If you depend on an underlying client library, there's a good chance
that it has a timeout too, so you have to sync them.

- DataWriter.tell is now implemented in trait DataWriterClient by
writeRequestData
- *many more errors* in compilation. And want to migrate my code as
robust as possible.

Do you have some quick "change log" of backward incompatible changes and
suggestions how to cope with them?

Up until know, our documentation was a Github wiki.
This wiki is great as a starter, but very limited once a project grows:

   - community can't help fix documentation with Pull Requests
   - it cannot display multiple versions (like one per branch and tag).

This last point made difficult for use to write the documentation as soon
as we committed a change.

We're now in the process of migrating the documentation to sphinx, so we'll
be able to host multiple versions.
In short: we'll be better on this.

Now, regarding your own protocol support, we can help if we can have a look
at your code. It would be great if it was hosted on Github.

Cheers,

Stéphane

3

Unfortunately I cannot show you, this is product specific actions for akka-based product.

If you don’t mind, I’ll post here questions regarded to migration:

What I’m stub now is
https://github.com/excilys/gatling/blob/master/gatling-core/src/main/scala/io/gatling/core/action/builder/ActionBuilder.scala
have private methods now.

But I have code:


class DestroyInstanceBuilder(name: Expression[String])(implicit api: ClientApi) extends ActionBuilder {
override def build(next: ActorRef): ActorRef = {
system.actorOf(Props(new DestroyInstanceAction(name, next)))
}
}

where I cannot use build now since it is private for not gatling namespace.

4

private modifier removed

5

wow, this was quick, thanks.

6

You’re welcome.

Those APIs weren’t public in Gatling 1, and Gatling 2 aims at cleaning them so they can be made public and people can extend them, so any feedback is welcome :slight_smile:

7

I don’t have experience in 1, I just did something that worked on 2.0.M3a, but have a terrible issue (I don’t understand root cause https://github.com/excilys/gatling/issues/1316), that cause that reports are never generated in longer cases.
And what is strange that those api used to be open in 2.0.M3a. Was a surprise.

Some kind of feedback what I have now, would be nice to extend reports just with custom metrics due to time of testing. E.g. what was cpu, memory and jmx, maybe some specifics, I do know that this is not exactly client, but still, when we do short tests in sbt (server is a fork), it is just convenient to see what have happened with system and garbaging. Adding graphite or any other monitoring in this case, imho, overkill.

8

Stéphane,

I have


class DestroyedCheck() extends Check[Map[RelativeComponentId, ComponentStatus]] {
override def check(statuses: Map[RelativeComponentId, ComponentStatus], session: Session)(implicit cache: mutable.Map[Any, Any]): Validation[Session] = {
if (statuses.isEmpty) session.success
else s"Components ${statuses.keys.mkString("'", "', '", "'") } are still alive".failure
}
}

I don’t understand what I should return to make “check” type of “Validation[Session => Session]”

Thanks in advance,
Dmytro

9

Hi,

In 2M3, checks were directly applied on the Session. Now, they produces changes to be applied on a Session.
This change was necessary so that we can deal with asynchronous requests in a scatter-gather way.

In your case, you probably just have to change:
if (statuses.isEmpty) identity.success // or maybe identity[Session].success if the compiler can’t guess the type

10

Thanks for a tip. Following did a compile magic:
(identity[Session] _).success

Provided internal comment to keep it memories. Would be nice to have some implicits, to have it nicer.

11

oh, load dsl was totally refactored and InjectionSupport introduced.

def ramp(users: UserNumber) becomes def rampUsers(users: Int)

less humman-like, but easier to understand. What was the goal of this? This seems used since api 1. :slight_smile:

12

Because ramp(10 users) involved an implicit, and it broke several use cases, for example:

val nbUsers = Integer.getInteger(“systemPropName”, 1)

ramp(nbUsers users) // won’t compile because it would involve 2 implicits: one from java.lang.Integer to scala.Int, and one from Int to UserNumber

13

Pitty, seems I’ll need to backport 2.0.0-M3a to apply DataWriter fix.
Everything caused due to we use akka 2.1.4 and gatling’s 2.2.4 causes runtime issues. I don’t quite understand how it is better to split Gatling and our Product in actors world, both akka-based.

Migration to 2.2.4 is on a roadmap, but too far comparing to the need have a performance tests.

14

Sorry to hear that.
Akka 2.2.0 was released in June 2013, almost 10 months ago, so it’s quite natural that Gatling latest version targets at least this version.
Actually, Akka 2.3.0 is already out, but we’re restraining from upgrading in 2M4 as some users mix Gatling and their own actors the way you do, but use Akka 2.2 and are not ready to upgrade to 2.3. 2M5 will target 2.3.

15

Stéphane,

Migration to new gatling snapshot went well.
With gatling-sbt-plugin, this is amazing and simple.

Regards,
Dmytro

16

Glad to hear!