i.g.h.a.AsyncHandler - Request failed: Received fatal alert: bad_record_mac

Hi there,
in approximately 1% of my requests ( 40 users /sec over 2400 secs) to a nginx Web server we get this error which indicates problems with establishing ssl connections.

That error cannot be reproduced for a dedicated connection, it happens statistically.

Is there any hint how to prevent it.
Thanks in advance


Gatling version?

Gatling 2.0.0-M3a
JDK 1.7.0_45

2M3a was using Netty 3.6.6.

IIRC, Netty fixed several SSL issues since then. Could you try upgrading to 3.9.0, please?

I replaced netty-3.6.6 in the lib-sir by betty-3.9.0.Final, but it doesn’t help.

Could you try adding the following System properties to your launch script, please?

-Dhttps.protocols=SSLv3 -Dforce.http.jre.executor=true

This problem seems to affect tons of different projects, and it seems no one has a clue, e.g.:

Hi Stephane,
i added it right after -server in the gatling.sh script, but the problem remains.

See my previous email, it seems even very smart people have digging this out.
Do you run with Hotspot or OpenJDK? Someone suggested on the ruby issue that OpenJDK doesn’t exhibit the problem.

Hi Stéphane,
I used a virtual machine to install openJDK. Starting Gatling-2.0.0M3a on this platform, the bad_record_mac error doesn’t appear any more. My test runs meanwhile for 16 minutes simulating 20 users per second without any error.


Wow. So it really sounds like an Hotspot bug!
If you’re adventurous, you can raise an issue against Hotspot, but I guess they’ll want a test case to reproduce.

I’m afraid I won’t be able to do anything more than just mention this in the FAQ.

Thanks a lot for your feedback.

Hello Stéphane,
I installed just now Java 8 on my Macbook Pro and reconfigured eclipse to use JDK8. I use another test case with 20 users per second, and until now 600 sec after start, there are no ‘bad_record_mac’ errors.
Therefore, JDK 8 seems to be a good choice for gatling 2.

That’s great news, thanks!