jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Deprecate Java Implementation in HTTP Request before dropping it in N+2 version ?
Date Fri, 04 Mar 2016 23:45:22 GMT
What do you think of dropping Java Implementation in 3.1 version ?

I see many issues in keeping it:

   - More work to maintain Http Request
   - Algorithm complexity to handle this additional implementation
   - The implementation is very limited compared to HC4 (it appears only
   GET/POST/PUT are supported in our implementation)
   - Features of HttpHC4Implementation are not supported, so it can be
   disturbing when you switch between implementation that you lose some
      - It does not support the following methods: COPY, LOCK, MKCOL, MOVE,
      - It does not support Kerberos Auth
      - https.use.cached.ssl.context
      - There is no control over how connections are re-used. When a
      connection is released by JMeter, it may or may not be re-used
by the same
      - The API is best suited to single-threaded usage - various settings
      are defined via system properties, and therefore apply to all connections.
      - There is a bug in the handling of HTTPS via a Proxy (the CONNECT is
      not handled correctly). See Java bugs 6226610 and 6208335.
      - It does not support virtual hosts.
      - It does not support client based certificate testing with Keystore
      - Digest Auth

In my experience there is only one case I see where it was useful
,sometimes recording fails and only Java Impl is able to record:

   - I think bug is .

So maybe we should deprecate it in 3.0 and ask users who are facing issues
with HC4 to report any problem.

If nothing is reported we disable it in 3.1 (make it possible to enable it
by a property) and drop it in 3.2.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message