Re: [JMeter] HTTP Sampler consolidation of implementations

On 3 April 2011 23:19, Milamber <[email protected]> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>