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 <
[email protected]> 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 <
> [email protected]> 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.
