Running a simple scenario in both Gatling in Firefox will demonstrate the bug.
In both cases, the scenario starts out the same:
We send a request: GET /VismaSchool.Web/ HTTP/1.1
We recieve the following response:
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Object moved to here.
- Now, watch what happens:
Firefox sends the following request: GET /VismaSchool.Web/Account/LogOn?ReturnUrl=%2FVismaSchool.Web%2F HTTP/1.1
Gatling sends the following request: GET /VismaSchool.Web/Account/LogOn%3FReturnUrl=%252FVismaSchool.Web%252F HTTP/1.1
In Firefox, it works as expected, but Gatling obviously recieves a 404.
You probably run into the following issue:
Could you try the 1.4.0-SNAPSHOT, please?
This fix has been backported into the 1.3 maintenance branch, and we plan to release 1.3.5 tomorrow.
I should add that I was using gatling-charts-highcharts-1.3.4.
Did you notice my previous email asking you to tests with 1.4 snapshot?
I did not. I will do that
Ok, so I downloaded gatling-bundle-1.4.0-20121120.112801-46-bundle.zip and tried again. Sadly, I get an exception when I try to generate the report:
Exception in thread “main” java.lang.NoClassDefFoundError: com/excilys/ebi/gatling/charts/component/impl/ComponentLibraryImpl
However, the simulation.log file shows that I have a lot less 404s now than before. I still have one KO, but I can’t tell what’s the cause of that at this moment. I may try to inspect that one further, tomorrow.
You’ll have to download gatling-charts-highcharts snapshot.
gatling-bundle doesn’t include the charting engine (license issues with Highcharts/Highstock, the charting libraries we use in Gatling) and your exception basically means that the charting engine classes can’t be found.
You can generate the report from your existing simulation.log using the -ro option.
Oops, my mistake. Thanks! I’ll try again now