Ok for me for merge. But the default behavior must don't change and make
some strong tests to avoid regression before 3.1 RC1.
On 11/10/2016 20:37, Philippe Mouawad wrote:
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>
