tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From therealnewo...@gmail.com
Subject Re: Bug that spans tomcat and tomcat-native
Date Fri, 24 Jun 2016 17:11:43 GMT
On Fri, Jun 24, 2016 at 11:18 AM, Mark Thomas <markt@apache.org> wrote:
> On 24/06/2016 11:17, Rémy Maucherat wrote:
>> 2016-06-24 12:08 GMT+02:00 Mark Thomas <markt@apache.org>:
>>
>>> Thanks.
>>>
>>> I'm going to start some local performance testing to confirm I see
>>> similar results and, assuming I do, I'll start looking at fixing this
>>> for 1.2.x/9.0.x and back-porting.
>>>
>> Hum, the fix that was submitted doesn't make sense IMO since writes can be
>> async, so I don't see a way besides adding the "error clear" thing after
>> each operation [and we'll remove it once OpenSSL 1.1 is there if it
>> actually fixes it]. That's assuming this issue is real [I actually never
>> noticed anything during my many ab runs and they use a lot of threads, so I
>> have a hard time believing it is significant enough ;) ].
>
> I haven't been able to reproduce anything like this yet. So far I have
> only been testing with tc-native 1.2.x and Tomcat 9.0.x. I might need to
> test with 1.1.x and Tomcat 7.0.x, the versions used by the OP.
>
> I'm having trouble understanding how this is happening. I could imagine
> that HashMap becoming a problem if there was a high churn in Threads.
> I'm thinking of something like bursty traffic levels and an executor
> aggressively halting spare threads. I need to experiment with that as well.
>

I do not understand it either. Using the thread pool there is not much
thread churn so I am not sure why the problem gets as bad as it does.
I didn't look into what the hash table actually had in it. I just
noticed that the majority of a read threads time was spent waiting for
the lock to access this hash table. Once I added the call to
ERR_remove_thread_state the waiting basically disappeared.

For this test the traffic is constant. Each client thread creates one
connection and just keeps pushing requests for set number of requests,
so we aren't even creating new connections.

-nate

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message