You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2016/03/05 00:45:22 UTC
Deprecate Java Implementation in HTTP Request before dropping it in
N+2 version ?
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
Re: Deprecate Java Implementation in HTTP Request before dropping it
in N+2 version ?
Posted by Philippe Mouawad <ph...@gmail.com>.
Ok for me.
On Mon, Mar 21, 2016 at 2:44 PM, sebb <se...@gmail.com> wrote:
> 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 <ph...@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.
>
--
Cordialement.
Philippe Mouawad.
Re: Deprecate Java Implementation in HTTP Request before dropping it
in N+2 version ?
Posted by sebb <se...@gmail.com>.
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 <ph...@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 <ra...@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 <ph...@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.
Re: Deprecate Java Implementation in HTTP Request before dropping it
in N+2 version ?
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ra...@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 <ph...@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.
Re: Deprecate Java Implementation in HTTP Request before dropping it
in N+2 version ?
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
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 <ph...@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
>