jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Deprecate Java Implementation in HTTP Request before dropping it in N+2 version ?
Date Fri, 18 Mar 2016 21:30:37 GMT
Hello,
Any thoughts on this one ?

Some additional reasons:

   - What is the RFC supported ? With HttpClient we support RFC2616, which
   one do we support with Java when we delegate Redirection management to it ?

Thanks

On Sun, Mar 6, 2016 at 12:30 PM, Antonio Gomes Rodrigues <ra0077@gmail.com>
wrote:

> Hi,
>
> I never have to use Java implementation
>
> If HC3 and Java implementation are deprecated it will be great to remove it
> from GUI (and use only the propertie in jmeter.propertie)
>
> It will allow to:
> Don't disturb new comers with this choice
> Simplify the GUI
> Don't disturb user who don't care before
> Advanded user who have the need of it have still the choice (in the
> propertie file) before the remove of the feature
>
> Antonio
>
> 2016-03-05 0:45 GMT+01:00 Philippe Mouawad <philippe.mouawad@gmail.com>:
>
> > Hello,
> > 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
> >    feature:
> >       - It does not support the following methods: COPY, LOCK, MKCOL,
> MOVE,
> >       PATCH, PROPFIND, PROPPATCH, UNLOCK, REPORT, MKCALENDAR.
> >       - 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
> >       thread.
> >       - 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
> >       Config.
> >       - 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 https://bz.apache.org/bugzilla/show_bug.cgi?id=59101
> .
> >
> >
> > 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.
> > Regards
> > Philippe
> >
>



-- 
Cordialement.
Philippe Mouawad.

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