You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jakarta.apache.org by sebb <se...@gmail.com> on 2010/11/25 16:45:19 UTC
[JMeter] HTTP Sampler consolidation of implementations
Just a heads up that I'm currently working on trying to combine the
HTTP implementations (Java, HttpClient3) into a single GUI, with
run-time choice of implementation.
The rationale for this is that HttpClient 4 is now available, and it
would be good to add that, but I think we should keep HttpClient for
backwards compatibility and comparison.
Creating another GUI/Sampler set is easy enough, but it would be
useful to be able to switch implementations easily - currently that
requires switching samplers (e.g. by editting the JMX file).
The current plan is to allow the implementation to be specified on the
HTTP Request Defaults config screen as well as on the HTTP Request
screen.
The code is a bit involved, because the Config settings are processed
at run-time after the test plan has been built.
[But even the Sampler GUI needs to create the sampler before it can
store the sampler settings - and the implementation can then be
changed.]
Currently I use a Sampler Proxy that dispatches to the appropriate
implementation class.
These classes have to extend an abstract class that provides the
necessary methods to interface with the Proxy test element and thus
provide access to the test element properties.
That part seems to be working OK.
The next phase is to ensure that existing JMX files can be converted
(during load) to use the new sampler.
The intention is to keep the existing Java and HttpClient samplers, so
that subclasses will continue to work, but not expose them in the GUI.
I've not finally decided about the AJP sampler - it can be easily
converted, but I don't think there's much of a use case for switching
between AJP and another implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 December 2010 21:45, Milamber <mi...@apache.org> wrote:
> Hello,
>
> I have got last checkout last JMeter SVN, and executed ant's task dist.
> With a simple test plan, I have this error with a new HTTP HC4 sampler:
>
> 2010/12/06 21:08:45 ERROR - jmeter.threads.JMeterThread: Error while
> processing sampler 'Page2' :
> org.apache.commons.lang.NotImplementedException: Code is not implemented
> at
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:43)
> at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
> at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:970)
> at
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:956)
> at
> org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:369)
> at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:262)
> at java.lang.Thread.run(Thread.java:662)
>
> Have I forgot something?
No - I've not yet finished working on the HC4 sampler.
> Milamber
>
>
>
> Le 06/12/2010 11:35, sebb a ecrit :
>>
>>>>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>>>>
>>>>>>
>>>>>>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Your plan seems very well.
>>>>>>>>
>>>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>>>>> has three http samplers thus will introduce some confusing for a new
>>>>>>>> user? (what http sampler is the best for my test?)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> It will have to be documented.
>>>>>>>
>>>>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>>>>> JMeter interface code working correctly.
>>>>>>> So I did not want to replace HC3 with HC4.
>>>>>>>
>>>>>>> Once it is well established, HC3 can be made optional, at which point
>>>>>>> JMeter would revert to two choices again.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>>>>
>>>>>>>> Another ask: what will be the default sampler?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>>>>> with a JMeter property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>>>>>> be good for the evolution of federated http sampler.
>>>>>>>>
>>>>>>>> Milamber
>>>>>>>>
>>>>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>>>>> run-time choice of implementation.
>>>>>>>>>
>>>>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>>>>> backwards compatibility and comparison.
>>>>>>>>>
>>>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>>>>> useful to be able to switch implementations easily - currently that
>>>>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>>>>
>>>>>>>>> The current plan is to allow the implementation to be specified on the
>>>>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>>>>>> screen.
>>>>>>>>>
>>>>>>>>> The code is a bit involved, because the Config settings are processed
>>>>>>>>> at run-time after the test plan has been built.
>>>>>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>>>>>> store the sampler settings - and the implementation can then be
>>>>>>>>> changed.]
>>>>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>>>>>> implementation class.
>>>>>>>>> These classes have to extend an abstract class that provides the
>>>>>>>>> necessary methods to interface with the Proxy test element and thus
>>>>>>>>> provide access to the test element properties.
>>>>>>>>> That part seems to be working OK.
>>>>>>>>>
>>>>>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>>>>>> (during load) to use the new sampler.
>>>>>>>>>
>>>>>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>>>>>
>>>>>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>>>>>> converted, but I don't think there's much of a use case for switching
>>>>>>>>> between AJP and another implementation.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
I have got last checkout last JMeter SVN, and executed ant's task dist.
With a simple test plan, I have this error with a new HTTP HC4 sampler:
2010/12/06 21:08:45 ERROR - jmeter.threads.JMeterThread: Error while
processing sampler 'Page2' :
org.apache.commons.lang.NotImplementedException: Code is not implemented
at
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:43)
at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:970)
at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:956)
at
org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:369)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:262)
at java.lang.Thread.run(Thread.java:662)
Have I forgot something?
Milamber
Le 06/12/2010 11:35, sebb a ecrit :
>
>>>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>>>
>>>>>
>>>>>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Your plan seems very well.
>>>>>>>
>>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>>>> has three http samplers thus will introduce some confusing for a new
>>>>>>> user? (what http sampler is the best for my test?)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> It will have to be documented.
>>>>>>
>>>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>>>> JMeter interface code working correctly.
>>>>>> So I did not want to replace HC3 with HC4.
>>>>>>
>>>>>> Once it is well established, HC3 can be made optional, at which point
>>>>>> JMeter would revert to two choices again.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>>>
>>>>>>> Another ask: what will be the default sampler?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>>>> with a JMeter property.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>>>>> be good for the evolution of federated http sampler.
>>>>>>>
>>>>>>> Milamber
>>>>>>>
>>>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>>>> run-time choice of implementation.
>>>>>>>>
>>>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>>>> backwards compatibility and comparison.
>>>>>>>>
>>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>>>> useful to be able to switch implementations easily - currently that
>>>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>>>
>>>>>>>> The current plan is to allow the implementation to be specified on the
>>>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>>>>> screen.
>>>>>>>>
>>>>>>>> The code is a bit involved, because the Config settings are processed
>>>>>>>> at run-time after the test plan has been built.
>>>>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>>>>> store the sampler settings - and the implementation can then be
>>>>>>>> changed.]
>>>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>>>>> implementation class.
>>>>>>>> These classes have to extend an abstract class that provides the
>>>>>>>> necessary methods to interface with the Proxy test element and thus
>>>>>>>> provide access to the test element properties.
>>>>>>>> That part seems to be working OK.
>>>>>>>>
>>>>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>>>>> (during load) to use the new sampler.
>>>>>>>>
>>>>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>>>>
>>>>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>>>>> converted, but I don't think there's much of a use case for switching
>>>>>>>> between AJP and another implementation.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 December 2010 08:12, Milamber <mi...@apache.org> wrote:
> Hello,
>
>>> Previously, the "Web Server" section immediately above stopped this
>>> happening, because it has a minimum size that is slightly larger than
>>> was needed for the Protocol/Method/Encoding
>>>
>>> The screen is already quite tall, so I did not want to add another line to it.
>>>
>>> I can maybe shorten some of the labels as well - e.g. change "Protocol
>>> (default http)" to "Protocol ([http])" - this should still be clear
>>> enough.
>>>
>> Done.
>>
>
> Perhaps [http] is better than ([http]), more readable?
Good point, you're right - and it's shorter.
> Milamber
>
>>
>>>> Milamber
>>>>
>>>>
>>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>>
>>>>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Your plan seems very well.
>>>>>>
>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>>> has three http samplers thus will introduce some confusing for a new
>>>>>> user? (what http sampler is the best for my test?)
>>>>>>
>>>>>>
>>>>> It will have to be documented.
>>>>>
>>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>>> JMeter interface code working correctly.
>>>>> So I did not want to replace HC3 with HC4.
>>>>>
>>>>> Once it is well established, HC3 can be made optional, at which point
>>>>> JMeter would revert to two choices again.
>>>>>
>>>>>
>>>>>
>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>>
>>>>>> Another ask: what will be the default sampler?
>>>>>>
>>>>>>
>>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>>> with a JMeter property.
>>>>>
>>>>>
>>>>>
>>>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>>>> be good for the evolution of federated http sampler.
>>>>>>
>>>>>> Milamber
>>>>>>
>>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>>
>>>>>>
>>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>>> run-time choice of implementation.
>>>>>>>
>>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>>> backwards compatibility and comparison.
>>>>>>>
>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>>> useful to be able to switch implementations easily - currently that
>>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>>
>>>>>>> The current plan is to allow the implementation to be specified on the
>>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>>>> screen.
>>>>>>>
>>>>>>> The code is a bit involved, because the Config settings are processed
>>>>>>> at run-time after the test plan has been built.
>>>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>>>> store the sampler settings - and the implementation can then be
>>>>>>> changed.]
>>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>>>> implementation class.
>>>>>>> These classes have to extend an abstract class that provides the
>>>>>>> necessary methods to interface with the Proxy test element and thus
>>>>>>> provide access to the test element properties.
>>>>>>> That part seems to be working OK.
>>>>>>>
>>>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>>>> (during load) to use the new sampler.
>>>>>>>
>>>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>>>
>>>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>>>> converted, but I don't think there's much of a use case for switching
>>>>>>> between AJP and another implementation.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
>> Previously, the "Web Server" section immediately above stopped this
>> happening, because it has a minimum size that is slightly larger than
>> was needed for the Protocol/Method/Encoding
>>
>> The screen is already quite tall, so I did not want to add another line to it.
>>
>> I can maybe shorten some of the labels as well - e.g. change "Protocol
>> (default http)" to "Protocol ([http])" - this should still be clear
>> enough.
>>
> Done.
>
Perhaps [http] is better than ([http]), more readable?
Milamber
>
>>> Milamber
>>>
>>>
>>> Le 26/11/2010 00:28, sebb a ecrit :
>>>
>>>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> Your plan seems very well.
>>>>>
>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>>> has three http samplers thus will introduce some confusing for a new
>>>>> user? (what http sampler is the best for my test?)
>>>>>
>>>>>
>>>> It will have to be documented.
>>>>
>>>> In theory, HC4 will be the best, but it may take a while to get the
>>>> JMeter interface code working correctly.
>>>> So I did not want to replace HC3 with HC4.
>>>>
>>>> Once it is well established, HC3 can be made optional, at which point
>>>> JMeter would revert to two choices again.
>>>>
>>>>
>>>>
>>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>>
>>>>> Another ask: what will be the default sampler?
>>>>>
>>>>>
>>>> Currently it is the Java sampler, but I plan to make it configurable
>>>> with a JMeter property.
>>>>
>>>>
>>>>
>>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>>> be good for the evolution of federated http sampler.
>>>>>
>>>>> Milamber
>>>>>
>>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>>
>>>>>
>>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>>> run-time choice of implementation.
>>>>>>
>>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>>> backwards compatibility and comparison.
>>>>>>
>>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>>> useful to be able to switch implementations easily - currently that
>>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>>
>>>>>> The current plan is to allow the implementation to be specified on the
>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>>> screen.
>>>>>>
>>>>>> The code is a bit involved, because the Config settings are processed
>>>>>> at run-time after the test plan has been built.
>>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>>> store the sampler settings - and the implementation can then be
>>>>>> changed.]
>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>>> implementation class.
>>>>>> These classes have to extend an abstract class that provides the
>>>>>> necessary methods to interface with the Proxy test element and thus
>>>>>> provide access to the test element properties.
>>>>>> That part seems to be working OK.
>>>>>>
>>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>>> (during load) to use the new sampler.
>>>>>>
>>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>>
>>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>>> converted, but I don't think there's much of a use case for switching
>>>>>> between AJP and another implementation.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 2 December 2010 12:59, sebb <se...@gmail.com> wrote:
> On 2 December 2010 07:34, Milamber <mi...@apache.org> wrote:
>> Hello,
>>
>> I have tested your changes from svn. I have these issues:
>> * on HTTP Proxy server, in HTTP Sampler settings section, Type combo
>> list says "HTTP Request" and "HTTP Request HTTPClient". Does have not
>> need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)
>
> Good point; I'll fix that.
Done.
>> * On HTTP Request and HTTP Request Defaults, Content encoding's white
>> box disappears when you reduce the JMeter window's width. On my screen
>> (1440x900), when I launch JMeter trunk, with the initial JMeter size, on
>> the HTTP Request sampler, I don't see the white box of Content encoding
>> (label still visible)
>> (I thinks the problem is the FlowLayout in JPanel from UrlConfigGui)
>
> Yes, I need to fix that too.
Done.
Turned out to be quite easy - just needed to set the minimum size for the panel.
> Previously, the "Web Server" section immediately above stopped this
> happening, because it has a minimum size that is slightly larger than
> was needed for the Protocol/Method/Encoding
>
> The screen is already quite tall, so I did not want to add another line to it.
>
> I can maybe shorten some of the labels as well - e.g. change "Protocol
> (default http)" to "Protocol ([http])" - this should still be clear
> enough.
Done.
>> Milamber
>>
>>
>> Le 26/11/2010 00:28, sebb a ecrit :
>>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> Your plan seems very well.
>>>>
>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>>> has three http samplers thus will introduce some confusing for a new
>>>> user? (what http sampler is the best for my test?)
>>>>
>>> It will have to be documented.
>>>
>>> In theory, HC4 will be the best, but it may take a while to get the
>>> JMeter interface code working correctly.
>>> So I did not want to replace HC3 with HC4.
>>>
>>> Once it is well established, HC3 can be made optional, at which point
>>> JMeter would revert to two choices again.
>>>
>>>
>>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>>
>>>> Another ask: what will be the default sampler?
>>>>
>>> Currently it is the Java sampler, but I plan to make it configurable
>>> with a JMeter property.
>>>
>>>
>>>> AJP sampler seems not very used like sampler. Keep his independence will
>>>> be good for the evolution of federated http sampler.
>>>>
>>>> Milamber
>>>>
>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>
>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>> run-time choice of implementation.
>>>>>
>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>> backwards compatibility and comparison.
>>>>>
>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>> useful to be able to switch implementations easily - currently that
>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>
>>>>> The current plan is to allow the implementation to be specified on the
>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>> screen.
>>>>>
>>>>> The code is a bit involved, because the Config settings are processed
>>>>> at run-time after the test plan has been built.
>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>> store the sampler settings - and the implementation can then be
>>>>> changed.]
>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>> implementation class.
>>>>> These classes have to extend an abstract class that provides the
>>>>> necessary methods to interface with the Proxy test element and thus
>>>>> provide access to the test element properties.
>>>>> That part seems to be working OK.
>>>>>
>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>> (during load) to use the new sampler.
>>>>>
>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>
>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>> converted, but I don't think there's much of a use case for switching
>>>>> between AJP and another implementation.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 2 December 2010 07:34, Milamber <mi...@apache.org> wrote:
> Hello,
>
> I have tested your changes from svn. I have these issues:
> * on HTTP Proxy server, in HTTP Sampler settings section, Type combo
> list says "HTTP Request" and "HTTP Request HTTPClient". Does have not
> need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)
Good point; I'll fix that.
> * On HTTP Request and HTTP Request Defaults, Content encoding's white
> box disappears when you reduce the JMeter window's width. On my screen
> (1440x900), when I launch JMeter trunk, with the initial JMeter size, on
> the HTTP Request sampler, I don't see the white box of Content encoding
> (label still visible)
> (I thinks the problem is the FlowLayout in JPanel from UrlConfigGui)
Yes, I need to fix that too.
Previously, the "Web Server" section immediately above stopped this
happening, because it has a minimum size that is slightly larger than
was needed for the Protocol/Method/Encoding
The screen is already quite tall, so I did not want to add another line to it.
I can maybe shorten some of the labels as well - e.g. change "Protocol
(default http)" to "Protocol ([http])" - this should still be clear
enough.
> Milamber
>
>
> Le 26/11/2010 00:28, sebb a ecrit :
>> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>>
>>> Hello,
>>>
>>> Your plan seems very well.
>>>
>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>>> has three http samplers thus will introduce some confusing for a new
>>> user? (what http sampler is the best for my test?)
>>>
>> It will have to be documented.
>>
>> In theory, HC4 will be the best, but it may take a while to get the
>> JMeter interface code working correctly.
>> So I did not want to replace HC3 with HC4.
>>
>> Once it is well established, HC3 can be made optional, at which point
>> JMeter would revert to two choices again.
>>
>>
>>> (Actually, my understanding is the Java Http sampler is the legacy and
>>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>>
>>> Another ask: what will be the default sampler?
>>>
>> Currently it is the Java sampler, but I plan to make it configurable
>> with a JMeter property.
>>
>>
>>> AJP sampler seems not very used like sampler. Keep his independence will
>>> be good for the evolution of federated http sampler.
>>>
>>> Milamber
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not finally decided about the AJP sampler - it can be easily
>>>> converted, but I don't think there's much of a use case for switching
>>>> between AJP and another implementation.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
I have tested your changes from svn. I have these issues:
* on HTTP Proxy server, in HTTP Sampler settings section, Type combo
list says "HTTP Request" and "HTTP Request HTTPClient". Does have not
need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)
* On HTTP Request and HTTP Request Defaults, Content encoding's white
box disappears when you reduce the JMeter window's width. On my screen
(1440x900), when I launch JMeter trunk, with the initial JMeter size, on
the HTTP Request sampler, I don't see the white box of Content encoding
(label still visible)
(I thinks the problem is the FlowLayout in JPanel from UrlConfigGui)
Milamber
Le 26/11/2010 00:28, sebb a ecrit :
> On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
>
>> Hello,
>>
>> Your plan seems very well.
>>
>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
>> has three http samplers thus will introduce some confusing for a new
>> user? (what http sampler is the best for my test?)
>>
> It will have to be documented.
>
> In theory, HC4 will be the best, but it may take a while to get the
> JMeter interface code working correctly.
> So I did not want to replace HC3 with HC4.
>
> Once it is well established, HC3 can be made optional, at which point
> JMeter would revert to two choices again.
>
>
>> (Actually, my understanding is the Java Http sampler is the legacy and
>> reliable, and Hc3 is new challenger and is better for httpS request...)
>>
>> Another ask: what will be the default sampler?
>>
> Currently it is the Java sampler, but I plan to make it configurable
> with a JMeter property.
>
>
>> AJP sampler seems not very used like sampler. Keep his independence will
>> be good for the evolution of federated http sampler.
>>
>> Milamber
>>
>> Le 25/11/2010 15:45, sebb a ecrit :
>>
>>> Just a heads up that I'm currently working on trying to combine the
>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>> run-time choice of implementation.
>>>
>>> The rationale for this is that HttpClient 4 is now available, and it
>>> would be good to add that, but I think we should keep HttpClient for
>>> backwards compatibility and comparison.
>>>
>>> Creating another GUI/Sampler set is easy enough, but it would be
>>> useful to be able to switch implementations easily - currently that
>>> requires switching samplers (e.g. by editting the JMX file).
>>>
>>> The current plan is to allow the implementation to be specified on the
>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>> screen.
>>>
>>> The code is a bit involved, because the Config settings are processed
>>> at run-time after the test plan has been built.
>>> [But even the Sampler GUI needs to create the sampler before it can
>>> store the sampler settings - and the implementation can then be
>>> changed.]
>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>> implementation class.
>>> These classes have to extend an abstract class that provides the
>>> necessary methods to interface with the Proxy test element and thus
>>> provide access to the test element properties.
>>> That part seems to be working OK.
>>>
>>> The next phase is to ensure that existing JMX files can be converted
>>> (during load) to use the new sampler.
>>>
>>> The intention is to keep the existing Java and HttpClient samplers, so
>>> that subclasses will continue to work, but not expose them in the GUI.
>>>
>>> I've not finally decided about the AJP sampler - it can be easily
>>> converted, but I don't think there's much of a use case for switching
>>> between AJP and another implementation.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 25 November 2010 23:13, Milamber <mi...@apache.org> wrote:
> Hello,
>
> Your plan seems very well.
>
> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
> has three http samplers thus will introduce some confusing for a new
> user? (what http sampler is the best for my test?)
It will have to be documented.
In theory, HC4 will be the best, but it may take a while to get the
JMeter interface code working correctly.
So I did not want to replace HC3 with HC4.
Once it is well established, HC3 can be made optional, at which point
JMeter would revert to two choices again.
> (Actually, my understanding is the Java Http sampler is the legacy and
> reliable, and Hc3 is new challenger and is better for httpS request...)
>
> Another ask: what will be the default sampler?
Currently it is the Java sampler, but I plan to make it configurable
with a JMeter property.
> AJP sampler seems not very used like sampler. Keep his independence will
> be good for the evolution of federated http sampler.
>
> Milamber
>
> Le 25/11/2010 15:45, sebb a ecrit :
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
Your plan seems very well.
Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there
has three http samplers thus will introduce some confusing for a new
user? (what http sampler is the best for my test?)
(Actually, my understanding is the Java Http sampler is the legacy and
reliable, and Hc3 is new challenger and is better for httpS request...)
Another ask: what will be the default sampler?
AJP sampler seems not very used like sampler. Keep his independence will
be good for the evolution of federated http sampler.
Milamber
Le 25/11/2010 15:45, sebb a ecrit :
> Just a heads up that I'm currently working on trying to combine the
> HTTP implementations (Java, HttpClient3) into a single GUI, with
> run-time choice of implementation.
>
> The rationale for this is that HttpClient 4 is now available, and it
> would be good to add that, but I think we should keep HttpClient for
> backwards compatibility and comparison.
>
> Creating another GUI/Sampler set is easy enough, but it would be
> useful to be able to switch implementations easily - currently that
> requires switching samplers (e.g. by editting the JMX file).
>
> The current plan is to allow the implementation to be specified on the
> HTTP Request Defaults config screen as well as on the HTTP Request
> screen.
>
> The code is a bit involved, because the Config settings are processed
> at run-time after the test plan has been built.
> [But even the Sampler GUI needs to create the sampler before it can
> store the sampler settings - and the implementation can then be
> changed.]
> Currently I use a Sampler Proxy that dispatches to the appropriate
> implementation class.
> These classes have to extend an abstract class that provides the
> necessary methods to interface with the Proxy test element and thus
> provide access to the test element properties.
> That part seems to be working OK.
>
> The next phase is to ensure that existing JMX files can be converted
> (during load) to use the new sampler.
>
> The intention is to keep the existing Java and HttpClient samplers, so
> that subclasses will continue to work, but not expose them in the GUI.
>
> I've not finally decided about the AJP sampler - it can be easily
> converted, but I don't think there's much of a use case for switching
> between AJP and another implementation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 21 April 2011 01:57, sebb <se...@gmail.com> wrote:
> On 20 April 2011 22:30, Milamber <mi...@apache.org> wrote:
>> Hello,
>>
>> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
>> policy: ignore cookie seems don't works)
>
> Looks like this is a new bug - the example works correctly in JMeter 2.4.
>
> I must have messed something up when converting the HC3.1 sampler to
> the new class layout.
>
> I'll take a look shortly.
Fixed.
>
>> With JMeter trunk and HC3.1 sampler, if you test a website with a login page
>> which used a auth session ID cookie to keep track user session and *without*
>> a JMeter cookie manager, the connection works and we can accessed on
>> protected resources.
>> The normal case is: if no cookie manager, we don't have a access on
>> protected resources (we have a error 408 with tomcat examples)
>>
>>
>> (an example Webapp is provided with tomcat archive :
>> http://localhost:8080/examples/jsp/security/protected/
>> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml
>> before running tomcat)
>>
>> Simple test case.
>
> Thanks - well spotted!
>
>> Milamber
>>
>> Le 25/11/2010 16:45, sebb a ecrit :
>>
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 20 April 2011 22:30, Milamber <mi...@apache.org> wrote:
> Hello,
>
> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
> policy: ignore cookie seems don't works)
Looks like this is a new bug - the example works correctly in JMeter 2.4.
I must have messed something up when converting the HC3.1 sampler to
the new class layout.
I'll take a look shortly.
> With JMeter trunk and HC3.1 sampler, if you test a website with a login page
> which used a auth session ID cookie to keep track user session and *without*
> a JMeter cookie manager, the connection works and we can accessed on
> protected resources.
> The normal case is: if no cookie manager, we don't have a access on
> protected resources (we have a error 408 with tomcat examples)
>
>
> (an example Webapp is provided with tomcat archive :
> http://localhost:8080/examples/jsp/security/protected/
> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml
> before running tomcat)
>
> Simple test case.
Thanks - well spotted!
> Milamber
>
> Le 25/11/2010 16:45, sebb a ecrit :
>
> Just a heads up that I'm currently working on trying to combine the
> HTTP implementations (Java, HttpClient3) into a single GUI, with
> run-time choice of implementation.
>
> The rationale for this is that HttpClient 4 is now available, and it
> would be good to add that, but I think we should keep HttpClient for
> backwards compatibility and comparison.
>
> Creating another GUI/Sampler set is easy enough, but it would be
> useful to be able to switch implementations easily - currently that
> requires switching samplers (e.g. by editting the JMX file).
>
> The current plan is to allow the implementation to be specified on the
> HTTP Request Defaults config screen as well as on the HTTP Request
> screen.
>
> The code is a bit involved, because the Config settings are processed
> at run-time after the test plan has been built.
> [But even the Sampler GUI needs to create the sampler before it can
> store the sampler settings - and the implementation can then be
> changed.]
> Currently I use a Sampler Proxy that dispatches to the appropriate
> implementation class.
> These classes have to extend an abstract class that provides the
> necessary methods to interface with the Proxy test element and thus
> provide access to the test element properties.
> That part seems to be working OK.
>
> The next phase is to ensure that existing JMX files can be converted
> (during load) to use the new sampler.
>
> The intention is to keep the existing Java and HttpClient samplers, so
> that subclasses will continue to work, but not expose them in the GUI.
>
> I've not finally decided about the AJP sampler - it can be easily
> converted, but I don't think there's much of a use case for switching
> between AJP and another implementation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
policy: ignore cookie seems don't works)
With JMeter trunk and HC3.1 sampler, if you test a website with a login
page which used a auth session ID cookie to keep track user session and*
*without* *a JMeter cookie manager, the connection works and we can
accessed on protected resources.
The normal case is: if no cookie manager, we don't have a access on
protected resources (we have a error 408 with tomcat examples)
(an example Webapp is provided with tomcat archive :
http://localhost:8080/examples/jsp/security/protected/
don't forget to uncommented users/roles in
tomcat_home/conf/tomcat-users.xml before running tomcat)
Simple test case.
Milamber
Le 25/11/2010 16:45, sebb a ecrit :
> Just a heads up that I'm currently working on trying to combine the
> HTTP implementations (Java, HttpClient3) into a single GUI, with
> run-time choice of implementation.
>
> The rationale for this is that HttpClient 4 is now available, and it
> would be good to add that, but I think we should keep HttpClient for
> backwards compatibility and comparison.
>
> Creating another GUI/Sampler set is easy enough, but it would be
> useful to be able to switch implementations easily - currently that
> requires switching samplers (e.g. by editting the JMX file).
>
> The current plan is to allow the implementation to be specified on the
> HTTP Request Defaults config screen as well as on the HTTP Request
> screen.
>
> The code is a bit involved, because the Config settings are processed
> at run-time after the test plan has been built.
> [But even the Sampler GUI needs to create the sampler before it can
> store the sampler settings - and the implementation can then be
> changed.]
> Currently I use a Sampler Proxy that dispatches to the appropriate
> implementation class.
> These classes have to extend an abstract class that provides the
> necessary methods to interface with the Proxy test element and thus
> provide access to the test element properties.
> That part seems to be working OK.
>
> The next phase is to ensure that existing JMX files can be converted
> (during load) to use the new sampler.
>
> The intention is to keep the existing Java and HttpClient samplers, so
> that subclasses will continue to work, but not expose them in the GUI.
>
> I've not finally decided about the AJP sampler - it can be easily
> converted, but I don't think there's much of a use case for switching
> between AJP and another implementation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 April 2011 23:11, Milamber <mi...@apache.org> wrote:
>
>>> When Web server (Apache 2.2) uses mod_deflate to compress response data,
>>> the data remains compress data (in view results tree, we have the
>>> compress characters and getBytes() is the compressed length)
>>>
>>> I thinks that must add a code section in sample() method when JMeter
>>> reads response data, to decode GZip response if needs, like HC3Impl?
>>> (perhaps HC4 has a specific method to do this?)
>>>
>> HC4 should do this automatically, I think, but there was a bug whereby
>> it did not recognise some encoding methods:
>>
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>
>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>> JMeter trunk was recently updated to use).
>>
>> Can you check which version of HC4 you were using, and the
>> Content-type used by Apache 2.2?
>>
>
> I uses last JMeter with HC v4.1.1
> httpclient-4.1.1.jar
> httpmime-4.1.1.jar
> and
> httpcore-4.1.jar
>
> Response headers (extract) :
> Server: Apache/2.2.16 (Unix) DAV/2
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 70
>
> Request Headers:
> Connection: keep-alive
> Accept-Encoding: gzip,deflate
>
> (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue)
>
> Issue too with www.google.com
Thanks, that was useful, though strangely google would not gzip until
I added a User-Agent of Firefox. Accepting gzip was not enough.
Code now fixed - HC4 does support gzip decoding, but not by default.
> Milamber
>>
>>> Milamber
>>>
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not finally decided about the AJP sampler - it can be easily
>>>> converted, but I don't think there's much of a use case for switching
>>>> between AJP and another implementation.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
>> When Web server (Apache 2.2) uses mod_deflate to compress response data,
>> the data remains compress data (in view results tree, we have the
>> compress characters and getBytes() is the compressed length)
>>
>> I thinks that must add a code section in sample() method when JMeter
>> reads response data, to decode GZip response if needs, like HC3Impl?
>> (perhaps HC4 has a specific method to do this?)
>>
> HC4 should do this automatically, I think, but there was a bug whereby
> it did not recognise some encoding methods:
>
> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>
> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
> JMeter trunk was recently updated to use).
>
> Can you check which version of HC4 you were using, and the
> Content-type used by Apache 2.2?
>
I uses last JMeter with HC v4.1.1
httpclient-4.1.1.jar
httpmime-4.1.1.jar
and
httpcore-4.1.jar
Response headers (extract) :
Server: Apache/2.2.16 (Unix) DAV/2
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 70
Request Headers:
Connection: keep-alive
Accept-Encoding: gzip,deflate
(I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue)
Issue too with www.google.com
Milamber
>
>> Milamber
>>
>>
>> Le 25/11/2010 15:45, sebb a ecrit :
>>
>>> Just a heads up that I'm currently working on trying to combine the
>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>> run-time choice of implementation.
>>>
>>> The rationale for this is that HttpClient 4 is now available, and it
>>> would be good to add that, but I think we should keep HttpClient for
>>> backwards compatibility and comparison.
>>>
>>> Creating another GUI/Sampler set is easy enough, but it would be
>>> useful to be able to switch implementations easily - currently that
>>> requires switching samplers (e.g. by editting the JMX file).
>>>
>>> The current plan is to allow the implementation to be specified on the
>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>> screen.
>>>
>>> The code is a bit involved, because the Config settings are processed
>>> at run-time after the test plan has been built.
>>> [But even the Sampler GUI needs to create the sampler before it can
>>> store the sampler settings - and the implementation can then be
>>> changed.]
>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>> implementation class.
>>> These classes have to extend an abstract class that provides the
>>> necessary methods to interface with the Proxy test element and thus
>>> provide access to the test element properties.
>>> That part seems to be working OK.
>>>
>>> The next phase is to ensure that existing JMX files can be converted
>>> (during load) to use the new sampler.
>>>
>>> The intention is to keep the existing Java and HttpClient samplers, so
>>> that subclasses will continue to work, but not expose them in the GUI.
>>>
>>> I've not finally decided about the AJP sampler - it can be easily
>>> converted, but I don't think there's much of a use case for switching
>>> between AJP and another implementation.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 7 April 2011 00:07, sebb <se...@gmail.com> wrote:
> On 6 April 2011 23:36, Milamber <mi...@apache.org> wrote:
>>
>>> HC4 should do this automatically, I think, but there was a bug whereby
>>>
>>
>> I have found this problem too:
>> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
>> certificate (verisign, thawte, etc.) but doesn't works with self-signed
>> ssl certificate.
>> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?
>
> No, I forgot.
> That needs to be fixed so that all certificates are accepted, same as for HC3.
> I'll fix that shortly.
Fixed.
>> Milamber
>>
>>
>>> it did not recognise some encoding methods:
>>>
>>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>>
>>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>>> JMeter trunk was recently updated to use).
>>>
>>> Can you check which version of HC4 you were using, and the
>>> Content-type used by Apache 2.2?
>>>
>>>
>>>> Milamber
>>>>
>>>>
>>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>>
>>>>> Just a heads up that I'm currently working on trying to combine the
>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>>> run-time choice of implementation.
>>>>>
>>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>>> would be good to add that, but I think we should keep HttpClient for
>>>>> backwards compatibility and comparison.
>>>>>
>>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>>> useful to be able to switch implementations easily - currently that
>>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>>
>>>>> The current plan is to allow the implementation to be specified on the
>>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>>> screen.
>>>>>
>>>>> The code is a bit involved, because the Config settings are processed
>>>>> at run-time after the test plan has been built.
>>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>>> store the sampler settings - and the implementation can then be
>>>>> changed.]
>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>>> implementation class.
>>>>> These classes have to extend an abstract class that provides the
>>>>> necessary methods to interface with the Proxy test element and thus
>>>>> provide access to the test element properties.
>>>>> That part seems to be working OK.
>>>>>
>>>>> The next phase is to ensure that existing JMX files can be converted
>>>>> (during load) to use the new sampler.
>>>>>
>>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>>
>>>>> I've not finally decided about the AJP sampler - it can be easily
>>>>> converted, but I don't think there's much of a use case for switching
>>>>> between AJP and another implementation.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 April 2011 23:36, Milamber <mi...@apache.org> wrote:
>
>> HC4 should do this automatically, I think, but there was a bug whereby
>>
>
> I have found this problem too:
> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
> certificate (verisign, thawte, etc.) but doesn't works with self-signed
> ssl certificate.
> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?
No, I forgot.
That needs to be fixed so that all certificates are accepted, same as for HC3.
I'll fix that shortly.
> Milamber
>
>
>> it did not recognise some encoding methods:
>>
>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>
>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>> JMeter trunk was recently updated to use).
>>
>> Can you check which version of HC4 you were using, and the
>> Content-type used by Apache 2.2?
>>
>>
>>> Milamber
>>>
>>>
>>> Le 25/11/2010 15:45, sebb a ecrit :
>>>
>>>> Just a heads up that I'm currently working on trying to combine the
>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>>> run-time choice of implementation.
>>>>
>>>> The rationale for this is that HttpClient 4 is now available, and it
>>>> would be good to add that, but I think we should keep HttpClient for
>>>> backwards compatibility and comparison.
>>>>
>>>> Creating another GUI/Sampler set is easy enough, but it would be
>>>> useful to be able to switch implementations easily - currently that
>>>> requires switching samplers (e.g. by editting the JMX file).
>>>>
>>>> The current plan is to allow the implementation to be specified on the
>>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>>> screen.
>>>>
>>>> The code is a bit involved, because the Config settings are processed
>>>> at run-time after the test plan has been built.
>>>> [But even the Sampler GUI needs to create the sampler before it can
>>>> store the sampler settings - and the implementation can then be
>>>> changed.]
>>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>>> implementation class.
>>>> These classes have to extend an abstract class that provides the
>>>> necessary methods to interface with the Proxy test element and thus
>>>> provide access to the test element properties.
>>>> That part seems to be working OK.
>>>>
>>>> The next phase is to ensure that existing JMX files can be converted
>>>> (during load) to use the new sampler.
>>>>
>>>> The intention is to keep the existing Java and HttpClient samplers, so
>>>> that subclasses will continue to work, but not expose them in the GUI.
>>>>
>>>> I've not finally decided about the AJP sampler - it can be easily
>>>> converted, but I don't think there's much of a use case for switching
>>>> between AJP and another implementation.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
> HC4 should do this automatically, I think, but there was a bug whereby
>
I have found this problem too:
Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
certificate (verisign, thawte, etc.) but doesn't works with self-signed
ssl certificate.
I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?
Milamber
> it did not recognise some encoding methods:
>
> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>
> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
> JMeter trunk was recently updated to use).
>
> Can you check which version of HC4 you were using, and the
> Content-type used by Apache 2.2?
>
>
>> Milamber
>>
>>
>> Le 25/11/2010 15:45, sebb a ecrit :
>>
>>> Just a heads up that I'm currently working on trying to combine the
>>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>>> run-time choice of implementation.
>>>
>>> The rationale for this is that HttpClient 4 is now available, and it
>>> would be good to add that, but I think we should keep HttpClient for
>>> backwards compatibility and comparison.
>>>
>>> Creating another GUI/Sampler set is easy enough, but it would be
>>> useful to be able to switch implementations easily - currently that
>>> requires switching samplers (e.g. by editting the JMX file).
>>>
>>> The current plan is to allow the implementation to be specified on the
>>> HTTP Request Defaults config screen as well as on the HTTP Request
>>> screen.
>>>
>>> The code is a bit involved, because the Config settings are processed
>>> at run-time after the test plan has been built.
>>> [But even the Sampler GUI needs to create the sampler before it can
>>> store the sampler settings - and the implementation can then be
>>> changed.]
>>> Currently I use a Sampler Proxy that dispatches to the appropriate
>>> implementation class.
>>> These classes have to extend an abstract class that provides the
>>> necessary methods to interface with the Proxy test element and thus
>>> provide access to the test element properties.
>>> That part seems to be working OK.
>>>
>>> The next phase is to ensure that existing JMX files can be converted
>>> (during load) to use the new sampler.
>>>
>>> The intention is to keep the existing Java and HttpClient samplers, so
>>> that subclasses will continue to work, but not expose them in the GUI.
>>>
>>> I've not finally decided about the AJP sampler - it can be easily
>>> converted, but I don't think there's much of a use case for switching
>>> between AJP and another implementation.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 3 April 2011 23:19, Milamber <mi...@apache.org> wrote:
> Hello,
>
> Currently I works to add a optional property to get response size (in
> bytes) by different methods:
> 1/ default (responses data size (uncompressed length if gzip)
> 2/ responses headers length + default (response data size)
> 2/ responses headers length + content-length value (real size if gzip)
> See:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50170
>
> When I testing my future patch, I found this bug on HC4 Impl:
>
> When Web server (Apache 2.2) uses mod_deflate to compress response data,
> the data remains compress data (in view results tree, we have the
> compress characters and getBytes() is the compressed length)
>
> I thinks that must add a code section in sample() method when JMeter
> reads response data, to decode GZip response if needs, like HC3Impl?
> (perhaps HC4 has a specific method to do this?)
HC4 should do this automatically, I think, but there was a bug whereby
it did not recognise some encoding methods:
https://issues.apache.org/jira/browse/HTTPCLIENT-1063
As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
JMeter trunk was recently updated to use).
Can you check which version of HC4 you were using, and the
Content-type used by Apache 2.2?
> Milamber
>
>
> Le 25/11/2010 15:45, sebb a ecrit :
>> Just a heads up that I'm currently working on trying to combine the
>> HTTP implementations (Java, HttpClient3) into a single GUI, with
>> run-time choice of implementation.
>>
>> The rationale for this is that HttpClient 4 is now available, and it
>> would be good to add that, but I think we should keep HttpClient for
>> backwards compatibility and comparison.
>>
>> Creating another GUI/Sampler set is easy enough, but it would be
>> useful to be able to switch implementations easily - currently that
>> requires switching samplers (e.g. by editting the JMX file).
>>
>> The current plan is to allow the implementation to be specified on the
>> HTTP Request Defaults config screen as well as on the HTTP Request
>> screen.
>>
>> The code is a bit involved, because the Config settings are processed
>> at run-time after the test plan has been built.
>> [But even the Sampler GUI needs to create the sampler before it can
>> store the sampler settings - and the implementation can then be
>> changed.]
>> Currently I use a Sampler Proxy that dispatches to the appropriate
>> implementation class.
>> These classes have to extend an abstract class that provides the
>> necessary methods to interface with the Proxy test element and thus
>> provide access to the test element properties.
>> That part seems to be working OK.
>>
>> The next phase is to ensure that existing JMX files can be converted
>> (during load) to use the new sampler.
>>
>> The intention is to keep the existing Java and HttpClient samplers, so
>> that subclasses will continue to work, but not expose them in the GUI.
>>
>> I've not finally decided about the AJP sampler - it can be easily
>> converted, but I don't think there's much of a use case for switching
>> between AJP and another implementation.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
Hello,
Currently I works to add a optional property to get response size (in
bytes) by different methods:
1/ default (responses data size (uncompressed length if gzip)
2/ responses headers length + default (response data size)
2/ responses headers length + content-length value (real size if gzip)
See:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
https://issues.apache.org/bugzilla/show_bug.cgi?id=50170
When I testing my future patch, I found this bug on HC4 Impl:
When Web server (Apache 2.2) uses mod_deflate to compress response data,
the data remains compress data (in view results tree, we have the
compress characters and getBytes() is the compressed length)
I thinks that must add a code section in sample() method when JMeter
reads response data, to decode GZip response if needs, like HC3Impl?
(perhaps HC4 has a specific method to do this?)
Milamber
Le 25/11/2010 15:45, sebb a ecrit :
> Just a heads up that I'm currently working on trying to combine the
> HTTP implementations (Java, HttpClient3) into a single GUI, with
> run-time choice of implementation.
>
> The rationale for this is that HttpClient 4 is now available, and it
> would be good to add that, but I think we should keep HttpClient for
> backwards compatibility and comparison.
>
> Creating another GUI/Sampler set is easy enough, but it would be
> useful to be able to switch implementations easily - currently that
> requires switching samplers (e.g. by editting the JMX file).
>
> The current plan is to allow the implementation to be specified on the
> HTTP Request Defaults config screen as well as on the HTTP Request
> screen.
>
> The code is a bit involved, because the Config settings are processed
> at run-time after the test plan has been built.
> [But even the Sampler GUI needs to create the sampler before it can
> store the sampler settings - and the implementation can then be
> changed.]
> Currently I use a Sampler Proxy that dispatches to the appropriate
> implementation class.
> These classes have to extend an abstract class that provides the
> necessary methods to interface with the Proxy test element and thus
> provide access to the test element properties.
> That part seems to be working OK.
>
> The next phase is to ensure that existing JMX files can be converted
> (during load) to use the new sampler.
>
> The intention is to keep the existing Java and HttpClient samplers, so
> that subclasses will continue to work, but not expose them in the GUI.
>
> I've not finally decided about the AJP sampler - it can be easily
> converted, but I don't think there's much of a use case for switching
> between AJP and another implementation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org