jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: BUG 53039 / Handling correctly responses that exceed Integer.MAX_VALUE
Date Tue, 11 Oct 2016 20:16:13 GMT
Am 11.10.2016 um 21:37 schrieb Philippe Mouawad:
> Hello,
> Unless there is a nogo, I'll be commiting the patch tomorrow evening.
Is old public method o.a.j.samplers.SampleResult#setBodySize(int) 
missing after the patch?

Javadoc in o.a.j.protocol.http.sampler.HTTPAbstractImpl "Invokes ... 
InputStream, int) ...", shouldn't it be "...InputStream, long)..."?

Comment in 
o.a.j.protocol.http.sampler.HTTPFileImpl#MAX_BYTES_TO_STORE_PER_REQUEST 
... default value: *false*; shouldn't it be 10 MB?

Could a o.a.commons.io.input.BoundedInputStream help to shorten our new 
code in o.a.j.protocol.http.sampler.HTTPFileImpl?

Comments in o.a.j.protocol.http.sampler.HTTPSamplerBase same as those in 
HTTPFileImpl.

Thanks for your work on this,
  Felix
>
> Regards
> Philippe
>
> On Monday, October 10, 2016, Philippe Mouawad <p.mouawad@ubik-ingenierie.com>
> wrote:
>
>> Hello ,
>> Any feedback on this ?
>> I think it should be fixed before next release as it appears for now that
>> we cannot handle big downloads.
>>
>> Regards
>> Philippe
>>
>> On Sat, Oct 8, 2016 at 9:25 PM, Philippe Mouawad <
>> p.mouawad@ubik-ingenierie.com
>> <javascript:_e(%7B%7D,'cvml','p.mouawad@ubik-ingenierie.com');>> wrote:
>>
>>> Hello,
>>> I have attached to BUG 53039 a first patch to handle the bug.
>>>
>>> There are several decisions to take regarding this piece of work:
>>>
>>>     - Introduce a new property that controls how much data from the
>>>     response we store (httpsampler.max_bytes_to_store_per_request).
>>>     Indeed we are limited by array size which is lower than Integer.MAX_VALUE
>>>     and even without that, JMeter would not scale if we really save the whole
>>>     response. I consider that if response is bigger than a certain limit, the
>>>     response is most probably a binary where assertion will be a size of a md5
>>>     hash.
>>>     - Introduce a new property to protect JMeter from big content length
>>>     (httpsampler.max_buffer_size). Today we would fail even without this issue
>>>     with an OOM due to size of array to allocate.
>>>     - backward compatibility of return methods, I think we need to
>>>     introduce getBytesAsLong and deprecate getBytes(). I'll update patch with
>>>     this.
>>>
>>>
>>>
>>> Regards
>>> Philippe M.
>>>
>>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>> Ubik-Ingénierie
>>
>> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
>>
>> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
>>
>>


Mime
View raw message