tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: SEVERE message from DeltaManager
Date Fri, 16 Jul 2010 14:33:10 GMT
On 16/07/2010 14:50, Luciano Fioriti wrote:
> I had done a stress test with 20 contemporary request to a web app using
> tomcat6 6bit.
> When maxThreads=200 tomcat gave response to only some request  then went to
> 0 cpu time
> no more response, nothing on log file.
> This happenend only on contemporary requests (max threads reched i presume).
> Increasing maxThreads to 250 all request were satisfied.

Which has absolutely nothing to do with the error Matt is reporting.

There are various things that look odd in the statements above but this 
thread isn't the place to go into that.

Mark

>
> Lucio
>
> 2010/7/16 Mark Thomas<markt@apache.org>
>
>> On 16/07/2010 14:19, Luciano Fioriti wrote:
>>
>>> It may be caused by maxThreads parameter in http connector, try to
>>> increase
>>>
>>
>> On what basis are you reaching that conclusion?
>>
>> Mark
>>
>>
>>
>>
>>> lucio
>>>
>>> 2010/7/16 Mark Thomas<markt@apache.org>
>>>
>>>   On 16/07/2010 06:49, Matt Peterson wrote:
>>>>
>>>>   While load testing our clustered Tomcats, we are seeing the following
>>>>> stack
>>>>> trace in our catalina.out occasionally, but not regularly:
>>>>>
>>>>>
>>>>>
>>>>> Jul 16, 2010 3:34:49 PM org.apache.catalina.ha.session.DeltaManager
>>>>> messageReceived
>>>>>
>>>>> SEVERE: Manager [localhost#/urs]: Unable to receive message through TCP
>>>>> channel
>>>>>
>>>>> java.lang.IllegalStateException: removeAttribute: Session already
>>>>> invalidated
>>>>>
>>>>>
>>>> <snip/>
>>>>
>>>>
>>>>   Under what conditions would this occur? Could it be that a session diff
>>>> is
>>>>
>>>>> being transmitted, but the session it relates to has been invalidated
by
>>>>> the
>>>>> time the diff is processed (via a user logout for example)? Or could
it
>>>>> be
>>>>> that a timeout has been reached???
>>>>>
>>>>>
>>>> Someone at $work has been doing a load test with tc Server (which has
>>>> identical code to Tomcat in this area) and seen the same issue. I know it
>>>> isn't due to timeout since the sessions are only a few seconds old when
>>>> it
>>>> happens. My current guess is that the messages are not being processed in
>>>> the same order as they are sent. I need to dig into this more to figure
>>>> out
>>>> if this is a configuration issue or a bug.
>>>>
>>>> I did wonder if switching to channel send options 6 would fix it. I'll
>>>> get
>>>> them to try that and see.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>




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


Mime
View raw message