2014-06-05 23:06 GMT+04:00 Christopher Schultz <ch...@christopherschultz.net>:
> On 6/5/14, 11:58 AM, Konstantin Kolinko wrote:
>> 2014-06-05 19:19 GMT+04:00 Christopher Schultz
>> <ch...@christopherschultz.net>:
>>> I tried invoking "backgroundProcess" on my Manager bean via JMX
>>> but it didn't seem to actually clean anything up. Is there any
>>> hope of recovery without bouncing the web application?
>>>
>>> Also, it would be nice to get a notification if the thread is
>>> dying due to some exception. I searched-though catalina.out and
>>> found nothing relevant. Any suggestions?
>>
>> In general, dying threads are handled via
>> Thread.setUncaughtExceptionHandler(...) and
>> ThreadGroup.uncaughtException(...)
>>
>> The default behaviour in JRE it so log to System.err. So
>> catalina.out is the place where I expect it to be written.
>
> That's what I would have thought, too. I didn't see anything,
> unfortunately.
>
>> (It is not nice as it bypasses logging framework, but that is how
>> it is currently).
>>
>> A unusual culprit is OutOfMemoryError.
>
> I think you mean "a usual culprit" and I agree: this has happened in
> the past where the background processor thread dies due to OOME.
>
Yes, a typo. I meant "a usual one".
>>> I tried invoking "backgroundProcess" on my Manager bean via JMX
>>> but it didn't seem to actually clean anything up. Is there any
>>> hope of recovery without bouncing the web application?
>>
>> The background thread is started via threadStart() which is called
>> from ContainerBase.startInternal() /
>> StandardContext.startInternal().
>>
>> So I see no hope of recovering unless the container that owns the
>> thread is stopped/started. I think that by default the thread is
>> started by Engine, so Engine needs to be bounced here.
>
> The JMX method "backgroundProcess" should call
> ManagerBase.backgroundProcess which should go ahead and expire the
> sessions. I don't see a reason why it wouldn't work. Unfortunately,
> Tomcat's Manager wasn't in debug-log mode or I would have been able to
> see what happened when I invoked backgroundProcess.
>
1. If you have Manager webapp installed, it has API to expire sessions
(on the "list" page in HTML gui)
2. I think logging level can be manipulated via JMX.
>> BTW, javadoc for ContainerBase.backgroundProcess() says "This
>> method will be invoked inside the classloading context of this
>> container." I think that is not true when it is being invoked via
>> JMX.
>
> This is ManagerBase.backgroundProcess, which does not have the same
> documentation. While ContainerBase.backgroundProcess would usually
> invoke ManagerBase.backgroundProcess, using JMX goes directly to
> ManagerBase.
OK.
> I'm still curious why invoking ManagerBase.backgroundProcess via JMX
> had no effect. I'm not sure what the "count" and
> "processExpiresFrequency" values were at the time, so my calls could
> have been rejected due to background-processing-throttling.
//ManagerBase.java
@Override
public void backgroundProcess() {
count = (count + 1) % processExpiresFrequency;
if (count == 0)
processExpires();
}
processExpiresFrequency should be readable via JMX.
Default is '6', so you have to call the method 6 times in a row.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
