jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: [JMeter] HTTP Sampler consolidation of implementations
Date Mon, 06 Dec 2010 21:45:06 GMT
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 <milamber@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


Mime
View raw message