Handling intermittent status 500 errors (2.0.2)

I am using Gatling to test a REST api that returns intermittent http 500 responses.
The service is hosted on Amazon and sits behind an ELB.

When sending requests manually from my browser (Chrome), I’ve found that quite often the service will initially return 500 and then 200 on a second try with the same data. So…it seems that http 500 is not a hard failure in this particular scenario.

To deal with this behavior, I’ve tried two things:

  1. GET requests use .repeat(2) and have a pause between tries. This helped boost the success rate, but there are still more failures than I would like to see.

  2. Modify check statement to look for 500 & 200. This also cleaned up error count, but some of the 200 responses got counted as errors. Not good!

I plan to file an issue with the development team because I think these 500 responses should be eliminated, but in the meanwhile, I would like my tests to be as accurate as possible.

It seems the key here is having better adaptability to retry requests if 500 is returned, but I’m not sure how to do that. Suggestions are welcome.

I’m currently using option 1 in my code >

// modified GET request with repeat & pause

val scnGetUserPostControlData = scenario(“GetPosts-User8218219433”)
.repeat(2) {
.get( “”"/path/to/gold/8218219433/bingo""")
.header(“id”, “9262222644”)


//typical console results:

---- Errors --------------------------------------------------------------------

status.find.in(200,304,201,202,203,204,205,206,207,208,209), b 995 (73.22%)

ut actually found 500

status.find.in(200,304,201,202,203,204,205,206,207,208,209), b 363 (26.71%)

ut actually found 403

save the status value and wrap the request in a asLongAs loop, like:
asLongAs(session => session(“status”).asOption[Int] match {
case Some(200) => false // exit loop
case _ => true // status is not defined yet, or is not 200, loop

Thanks for that suggestion. I will give it a try and let you know how it turns out.