tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: TC looping on CPU due to "Critical poller failure" when using APR (7.0.35, on reproducible)
Date Mon, 21 Jan 2013 11:39:11 GMT
On 21.01.2013 10:41, Konstantin Kolinko wrote:
> 2013/1/21 Rainer Jung <>:
>> I did another run for "ant test" for 7.0.35 and when using APR I got the
>> following error the first time (never saw that before):
>> (...)
>>     [junit] INFO: Stopping ProtocolHandler
>> ["http-apr-"]
>>     [junit] Jan 18, 2013 4:37:59 PM
>>$Poller doPoll
>>     [junit] SEVERE: Critical poller failure (restarting poller): [9] Bad
>> file number
>>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> OS is Solaris 10, using Java 1.6.0_37.
>> The ant and Tomcat processes are still there to investigate, Tomcat is
>> looping on CPU in Thread 26. Stack is:
>> (...)
> Well, it happens only during shutdown, so it might be that it is not
> so important...

It looks like the shutdown is part of the reason. See below.

> What is the downside here -- Tomcat hangs due to an infinite loop? If
> so then it is not good.

Yes, it hangs in an infinite loop.

> I wonder why that log message says "restarting poller". Does it try to
> start the poller when everything else shuts down?

The code following the failure first calls destroy(), then init().

>> This is an indication for a synchronization problem in the code using
>> the pool.

I'd speculate:

- the shutdown code somehow triggered the error message.

- then the shutdown code and the code running after the error both enter
"destroy" for the Poller (can be seen from the stack dump). It seems
method Poller.destroy() is not thread safe, because it calls destroy for
the pool without locking. Only the call coming from the error path has a
"synchronized", not the call coming from the shutdown path. That could
corrupt the allocator in the pool and lead to the infinite looping.

> I wonder whether some test case has higher chance of triggering this.
> The test case where it happened is "org.apache.jasper.compiler.TestParser" ?

Yes that was the test where it happened.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message