jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Deprecate Java Implementation in HTTP Request before dropping it in N+2 version ?
Date Mon, 21 Mar 2016 13:44:08 GMT
I think we should keep the Java implementation.

I agree it is not particularly suitable for load testing which is why
JMeter originally added HC3.x and then HC4.x.

However, it generally works OK for functional testing and is useful as
a comparison.

If there is a problem with a particular URL, it can be very helpful to
try it with a different implementation.

On 18 March 2016 at 21:30, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> 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
View raw message