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 Thu, 07 Apr 2011 00:50:37 GMT
On 6 April 2011 23:11, Milamber <milamber@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


Mime
View raw message