Folks I have been poking around the latest JMeter source and have found out HTTPSamplerBase and HTTPAbstractImpl classes are tightly coupled with Java classic I/O APIs (InputStream / OutputStream).
The problem here is that InputStream / OutputStream API are inherently blocking. This is not a bad thing as such: classic I/O has good performance characteristics, is well understood and supported. However, newer HTTP libraries tend to have even-driven (callback based) APIs. This is definitely the case with Apache HttpAsyncClient 5.0 and Jetty Client 9. While event-driven transport libraries can be retrofitted to work with InputStream / OutputStream based APIs it usually comes at a certain cost in terms of extra complexity and synchronization overhead. I would kindly ask you to consider investing some effort into decoupling HTTPSamplerBase and HTTPAbstractImpl from InputStream. This might especially become important for HTTP/2 support. I _believe_ there are HTTP/2 libraries based on the classic Socket APIs but current HTTPSamplerBase and HTTPAbstractImpl design precludes JMeter from leveraging many newer HTTP transport libraries in their native mode. I also _suspect_ that as of Java 13 that the classic Socket API may no longer have a performance edge over NIO. Oleg
