On Mar 30, 2010, at 11:59 AM, Andy Gumbrecht wrote:
> On 30.03.2010 16:18, Andy Gumbrecht wrote:
>> On 30.03.2010 16:01, Kevan Miller wrote:
>>> On Mar 29, 2010, at 7:00 PM, David Blevins wrote:
>>>
>>>> So that occasional deadlock at startup we're seeing on some of the tests
>>>> is cause by the ActiveMQ 5 upgrade. Kevin had poked at it a bit, but it's
>>>> still unresolved.
>>>>
>>>> Just now noticing that the standalone server shutdown is also not working,
>>>> just hangs forever at "Stopping ResourceAdapter: My JMS Resource Adapter"
>>>>
>>>> Couple release blocking issues if there's someone out there who is looking
>>>> for something to work on.
>>> Are you running with Java 5 or Java 6? And I assume you are running on Mac
>>> OS...
>>>
>>> I have not seen the startup deadlock on Mac OS Java 6. IMO, it's a JVM/JSE
>>> issue. I haven't tested extensively. If we're seeing this issue on other
>>> platforms (not Java 5 Mac OS), then there's more motivation to fix...
>>>
>>> --kevan
>>>
>> So had a look at the ActiveMQ code and find this bit of code in RA.stop():
>>
>> while (endpointWorkers.size() > 0) {
>> ActiveMQEndpointActivationKey key =
>> endpointWorkers.keySet().iterator().next();
>> endpointDeactivation(key.getMessageEndpointFactory(),
>> key.getActivationSpec());
>> }
>>
>> It assumes that endpointDeactivation() will definitely stop 'a' worker - no
>> time-out.
>> With no concrete error I am just guessing that this worker fails to stop for
>> 'whatever' reason, and blocks indefinitely.
>>
>> It seems to be related to: http://issues.apache.org/activemq/browse/AMQ-1447
>>
>> I am currently testing a possible solution, which basically gives up waiting
>> for RA.stop() after 5 seconds.
>>
>> Andy.
>>
>>
>
> This is could be related to the 'Remote Shutdown' issue.
>
> The RAs were not getting 'stopped' if the the remote stop was called - do any
> tests call remote stop (without first having looked)?
>
> If ActiveMQ is not shut-down cleanly then I have seen it hang on the first
> restart (only the first restart, and not always) while it fixes it's data,
> this could be the observed 'occasional' deadlock!
This may be a problem, but is different from the deadlock problem that I looked
at. Is there a Jira open? Do we have information on the deadlock?
The deadlock that I saw was a ClassLoader deadlock during a call to
ClassFileTransformer.transform(...)
--kevan
