jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject Re: BUG 53039 / Handling correctly responses that exceed Integer.MAX_VALUE
Date Mon, 10 Oct 2016 20:41:05 GMT
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> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message