Hi,
The Gatling 3 release announcement says:
We parted ways with AsyncHttpClient. Gatling now has its own internal HTTP client, still implemented on top of Netty, that supports HTTP/2 and solves the concurrent access complexity issues AsyncHttpClient has.
That sounds like an interesting change. What were the concurrent access complexity issues in AsyncHttpClient? Are there more details about this new HTTP client and how/why it came to be? Plans to package it as a standalone library?
That sounds like an interesting change. What were the concurrent access complexity issues in AsyncHttpClient?
In AHC, requests are responses are manipulated by 3 kinds of threads: calling threads, Netty eventloop threads and timer thread use to trigger timeouts. Makes real life use cases super complex, eg timeout triggers at the same time response is received, or request is being written at the same time remote peer closes the socket.
Are there more details about this new HTTP client and how/why it came to be?
We’ll soon public a blog post about it.
Plans to package it as a standalone library?
Definitively no.
One of the thing that motivated us was to no longer be bound to a public API that has to be stable so we can change things whenever we want and build something tailored to our needs instead of a generic purpose client.
Stéphane Landelle
GatlingCorp CTO
slandelle@gatling.io