jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JMeter] HTTP Sampler consolidation of implementations
Date Mon, 06 Dec 2010 11:35:12 GMT
On 6 December 2010 08:12, Milamber <milamber@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 <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


Mime
View raw message