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 08:12:29 GMT
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 <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


Mime
View raw message