Hello, Unless there is a nogo, I'll be commiting the patch tomorrow evening.
Regards Philippe On Monday, October 10, 2016, Philippe Mouawad <p.moua...@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.moua...@ubik-ingenierie.com > <javascript:_e(%7B%7D,'cvml','p.moua...@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> > > -- Cordialement. Philippe Mouawad. Ubik-Ingénierie UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>