-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 6/5/14, 4:27 PM, Konstantin Kolinko wrote:
> 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.
I hadn't thought of that. Next time. ;)
>>> 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.
Aah. I gave up after 3. Next time.
Thanks for the info!
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTkOEWAAoJEBzwKT+lPKRY9hwP/Azf+FdBNpEl/V29SjuVfAb/
GTkEwzcVyxFh0uzr1wydcjdw8vE/SeVYcL0++dWmjzV6qGPeVLY0/wbrASBfJckc
Cka8gbLpSnIaVkrGqEAqWvfisSXYY2UGpCh2raOzgRW8/kqKcwriNrxRyZ7vPXXo
v4Ql+J4mjBC+XN4RRqHnz//l0bRBuwYGUgfeew7Tv5hO32PfGV2GS6FtgsbceIP7
GDRpqFoBo9xQtmgYHvHIVYrRD7zSBFcf72YZdY23PIlQum6TdvxWjkt0KipNrRE8
N7mDBprddiuRv1q6vNjWJbkz+y+YROd4PlHpK/sCxhdQMfvpl4SpNXp2Uo0b6cBB
KiFjJ6i9HUcEbaHrRZXCS+UoOxBOhQM/WBRtPXv/Vy+k7hIyjtfs1QCojrwnQQcl
EMff7iDdukk+m2FlnK3SdbxJALGtVh1Y+Q3eYa+X3IqBoz7/RQDt1tBUjpm4eKkF
G+cg7/+JubJJh+2TMOHzi7YFsBo978TMMO3rmu+Bl3E4YHayzt0RMfde2V0Dj4jD
WJCQOFz/JYHRjZoeY/lJSx0Y9kydfNeqF/aQ5hlF1+c2PKVYVkwp5NG5H48yXjpo
E3HcDV0nSV69VmbWQKiZpGn74B5J9tHTLQ7KYFJRH0BpyOk+QZc0Zzh2zTtAnbyq
tRA2omkbjAifP0PA0IMg
=jS15
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
