jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Bug 58807
Date Wed, 28 Feb 2018 21:41:11 GMT
Hello,
Anybody had a chance to look at committed code regarding this bug ?

Thanks

On Sun, Feb 25, 2018 at 7:21 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> Hello,
> After further thinking,
>
> https.use.cached.ssl.context should be false by default and maybe instead
> of having 2 properties we should only have 1 property:
>
>    - httpclient.reset_state_on_thread_group_iteration
>       - It true we reset SSL Context and close connection on ThreadGroup
>       iteration
>       - If false we allow reuse of both
>
> And we would deprecate https.use.cached.ssl.context
>
> Thoughts ?
>
> Regards
>
> On Sat, Feb 24, 2018 at 10:48 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>> Hello,
>> I attached a patch to:
>> - https://bz.apache.org/bugzilla/show_bug.cgi?id=58807
>>
>> Hope somebody can have a look.
>>
>> Regards
>>
>> On Sat, Feb 24, 2018 at 7:06 PM, Philippe Mouawad <
>> philippe.mouawad@gmail.com> wrote:
>>
>>> Hello,
>>> While working on Migration to last HC4.5 APIs and testing Client
>>> Certificate (see another question on how to include tests for it), I
>>> confirmed that the bug reported by Rainer was still here.
>>>
>>> This bug has the following impact:
>>>
>>>    - Whenever you set "https.use.cached.ssl.context=false " which is
>>>    required for Client Certificate Testing, you end up :
>>>       - Replaying SSL Handshake on every sample while we shouldn't
>>>       - Losing KeepAlive
>>>    - Another thing he tackles is that fact that within Thread Group
>>>    iteration we reuse objects we shouldn't
>>>
>>> IMO, we need to tackle it,  looking at Rainer patch I agree with almost
>>> all his proposals except for what I describe below.
>>>
>>>
>>> Let's see use most  common cases :
>>>
>>>    - 0/ We are testing HTTP, Rainer is correct saying that when we
>>>    switch to next iteration and are using KeepAlive we use the same connection
>>>    while we shouldn't , this would be PROBLEM A below
>>>    - 1/ We are testing HTTPS only without client certificate, then
>>>    https.use.cached.ssl.context=true is ok within 1 thread group
>>>    iteration. What would be unrealistic is the fact that SSL Handshake will
>>>    not occur for next iteration. Let's call this case PROBLEM A.
>>>    - 2/ We are testing HTTPS only WITH client certificate, then since
>>>    https.use.cached.ssl.context=false is needed we have a problem
>>>    PROBLEM B.
>>>
>>> *ASSUMPTION:*
>>>
>>> First, I think that we should consider that Each Thread Group Iteration
>>> is a new user, indeed, If one  wants to make the same user loop, he can
>>> easily add a Loop Controller as child of Thread Group and it's ok.
>>>
>>> *So let's zoom to PROBLEM B first:*
>>>
>>>    - If we make the assumption above, part of the patch of Rainer can
>>>    be reused:
>>>       - Have a thread local hold the fact that reset occured, but Maybe
>>>       using JMeterVariables would be better particularly if one day we decide
to
>>>       switch to different model 1 VU == 1 Thread.
>>>       - What should be changed in Rainer patch is the SSL reset, indeed
>>>       for HC4.5 we need to close idle and expired connections to really reset
SSL
>>>       State
>>>       - What I don't get about Rainer patch is wether we should do the
>>>       close on all HTTPCLIENT Instances of VUs or not. I think we should but
It
>>>       would be great if another brain or more would confirm
>>>
>>> *Let's zoom to PROBLEM A:*
>>>
>>> In summary, whenever we make a new Thread Group iteration, we must start
>>> with new connections and not reuse existing ones.
>>>
>>> So Rainer patch looks ok to me.
>>>
>>> But:
>>>
>>> 1/ I would personally set default to
>>>
>>>    -
>>>
>>>    reuse.http.connections=false
>>>
>>>
>>> 2/ I would not introduce reuse.http.client
>>>
>>> 3/ I would not as a consequence reset HttpClient as it is not needed to reset
state if I am not wrong and it would
>>>
>>> introduce "initialization cost" in requests timing
>>>
>>> What's your thoughts ?
>>>
>>>
>>> --
>>> Regards
>>> Philippe M.
>>>
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message