You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2010/03/30 01:00:55 UTC
ActiveMQ 5 issues
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.
-David
Re: ActiveMQ 5 issues
Posted by Andy Gumbrecht <an...@orprovision.com>.
Well if I broke it then I should at least try and fix it, but I have to
say I have been using this extensively for quite a while now. It is fair
to say that I restart the standalone server at least 50 times a day
during testing and have not had a problem with ActiveMQ5.
However, I am using a custom configuration. So here is my configuration:
<Resource id="JMSResourceAdapter" type="ActiveMQResourceAdapter">
# Broker configuration URI as defined by ActiveMQ
# see http://activemq.apache.org/broker-configuration-uri.html
BrokerXmlConfig xbean:file:conf/activemq.xml
# Broker address
ServerUrl
tcp://127.0.0.1:54545?keepAlive=true&wireFormat.maxInactivityDuration=0
</Resource>
Using the following activemq.xml ([openejb]/conf/activemq.xml):
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:amq="http://activemq.apache.org/schema/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core-5.3.0.xsd">
<!-- Allows us to use system properties as variables in this
configuration file -->
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
<broker xmlns="http://activemq.apache.org/schema/core"
useJmx="false"
brokerName="myserver"
useShutdownHook="true"
persistent="true"
dataDirectory="data/activemq"
>
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource="#postgresql-activemq-ds"
lockKeepAlivePeriod="0"/>
</persistenceAdapter>
<!-- The transport connectors ActiveMQ will listen to -->
<transportConnectors>
<transportConnector
uri="tcp://0.0.0.0:54545?keepAlive=true&wireFormat.maxInactivityDuration=0"/>
</transportConnectors>
</broker>
<bean id="postgresql-activemq-ds"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="org.postgresql.Driver"/>
<property name="url"
value="jdbc:postgresql://myhost:5432/openejb_activemq"/>
<property name="username" value="myuser"/>
<property name="password" value="mypassword"/>
<property name="poolPreparedStatements" value="true"/>
</bean>
</beans>
I will have a play with the default configuration to see if something
needs to be weaved into the standard set-up.
Andy.
Re: ActiveMQ 5 issues
Posted by Kevan Miller <ke...@gmail.com>.
On Mar 31, 2010, at 8:45 AM, Andy Gumbrecht wrote:
> On 31.03.2010 14:09, Kevan Miller wrote:
>> 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
>>
>>
>>
>>
> And in what way was it (the deadlock) related to ActiveMQ?
IMO, it was only "related" in that the deadlock occurred while running an ActiveMQ test. ActiveMQ 5 would potentially exhibit different threading/classloading behavior than ActiveMQ 4. In the stack trace that I saw, I didn't see anything that indicated that ActiveMQ was doing something wrong.
The only platform that I've seen this error occur on is Mac OS Java 5. Unless we're seeing the problem on reasonably current Java service levels, I would ignore the Mac OS Java 5 problem.
--kevan
--kevan
Re: ActiveMQ 5 issues
Posted by Kevan Miller <ke...@gmail.com>.
I dug up the previous discussion of the problem that I know about... Resending on this thread...
On Feb 23, 2010, at 12:45 PM, Kevan Miller wrote:
>
> On Feb 23, 2010, at 2:04 AM, David Blevins wrote:
>
> <snip>
>
>> Started running into this again and with a little help from Brett Porter managed to get some heap dumps. I added the following flag and it redirects the output to a file which seems to be enough to get the heap dumps to show up somewhere:
>>
>> mvn clean install -Dmaven.test.redirectTestOutputToFile=true
>>
>> There's a buffer flushing issue in their "redirect" code, so you have to dump twice to build up enough bytes to flush the first dump completely.
>
> Interesting. Good to know. Thanks.
>
>>
>> Anyway, here's the output. I see a few "locked" items, but it isn't clear where the source is.
>>
> <snip>
>
>> Found one Java-level deadlock:
>> =============================
>> "VMTransport":
>> waiting to lock monitor 0x00819694 (object 0x07d11e58, a sun.misc.Launcher$AppClassLoader),
>> which is held by "main"
>> "main":
>> waiting to lock monitor 0x008196b8 (object 0x255a4b40, a [[I),
>> which is held by "VMTransport"
>>
>> Java stack information for the threads listed above:
>> ===================================================
>> "VMTransport":
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:242)
>> at org.apache.openejb.core.TempClassLoader.loadClass(TempClassLoader.java:92)
>> - locked <0x07f2a298> (a org.apache.openejb.core.TempClassLoader)
>> at org.apache.openejb.core.TempClassLoader.loadClass(TempClassLoader.java:66)
>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
>> - locked <0x07f2a298> (a org.apache.openejb.core.TempClassLoader)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:242)
>> at org.apache.openjpa.enhance.PCClassFileTransformer.needsEnhance(PCClassFileTransformer.java:186)
>> at org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:132)
>> at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:120)
>> at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.transform(PersistenceProviderImpl.java:210)
>> at org.apache.openejb.persistence.PersistenceUnitInfoImpl$PersistenceClassFileTransformer.transform(PersistenceUnitInfoImpl.java:303)
>> at sun.instrument.TransformerManager.transform(TransformerManager.java:122)
>> at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:155)
>> at java.util.concurrent.SynchronousQueue$LifoWaitQueue.enq(SynchronousQueue.java:162)
>> at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:437)
>> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:475)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>> at java.lang.Thread.run(Thread.java:613)
>> "main":
>> at java.lang.ClassLoader.findBootstrapClass(Native Method)
>> at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
>> - locked <0x07d14028> (a sun.misc.Launcher$ExtClassLoader)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> - locked <0x07d11e58> (a sun.misc.Launcher$AppClassLoader)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
>> - locked <0x07d11e58> (a sun.misc.Launcher$AppClassLoader)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
>> - locked <0x07d11e58> (a sun.misc.Launcher$AppClassLoader)
>> at org.apache.activemq.ActiveMQConnection.<init>(ActiveMQConnection.java:186)
>> at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:288)
>> at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:256)
>> at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:182)
>> at org.apache.activemq.ra.ActiveMQConnectionSupport.makeConnection(ActiveMQConnectionSupport.java:79)
>> at org.apache.activemq.ra.ActiveMQConnectionSupport.makeConnection(ActiveMQConnectionSupport.java:61)
>> at org.apache.activemq.ra.ActiveMQManagedConnectionFactory.createManagedConnection(ActiveMQManagedConnectionFactory.java:169)
>> at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getConnection(MCFConnectionInterceptor.java:48)
>> at org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor.getConnection(XAResourceInsertionInterceptor.java:41)
>> at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalGetConnection(SinglePoolConnectionInterceptor.java:67)
>> - locked <0x07ede778> (a org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor$PoolDeque)
>> at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
>> at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:46)
>> at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:94)
>> at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
>> at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
>> at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
>> at org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:87)
>> at org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:94)
>> at org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:67)
>> at org.apache.openejb.config.LocalClientTest.assertRefs(LocalClientTest.java:140)
>> at org.apache.openejb.config.LocalClientTest.test(LocalClientTest.java:118)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:592)
>> at junit.framework.TestCase.runTest(TestCase.java:168)
>> at junit.framework.TestCase.runBare(TestCase.java:134)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:124)
>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>> at junit.framework.TestSuite.run(TestSuite.java:227)
>> at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:592)
>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
>>
>> Found 1 deadlock.
>
> Yuck. This reminds me of a deadlock we had in Geronimo in the JVM's Finalizer thread. Also, involved a Classloader and a '[[' "object", IIRC. I'll see what I can remember about that one...
The Geronimo Jira was -- https://issues.apache.org/jira/browse/GERONIMO-3687
The Geronimo changes were really work arounds for an underlying JVM problem. IMO, we got lucky that we were able to work around the problem.
Here's some indication that the problem has been fixed in the JDK -- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5088398 -- that's the way to *fix* this problem.
--kevan
Re: ActiveMQ 5 issues
Posted by Andy Gumbrecht <an...@orprovision.com>.
On 31.03.2010 14:09, Kevan Miller wrote:
> 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
>
>
>
>
And in what way was it (the deadlock) related to ActiveMQ?
No there is not a Jira open - The 'Remote Shutdown' issue on the stand
alone server is most definitely fixed by the snippet posted in my mail
on the subject. It is such a small fix (in SimpleServiceManager.stop())
that I was hoping one of the devs could just plug it - researching the
proposed fix would seem excessive, as it is is obviously just a late
night 'doh!' bug.
If you want a Jira creating then let me know...
Andy
Re: ActiveMQ 5 issues
Posted by Kevan Miller <ke...@gmail.com>.
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
Re: ActiveMQ 5 issues
Posted by Andy Gumbrecht <an...@orprovision.com>.
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!
Andy.
Re: ActiveMQ 5 issues
Posted by Andy Gumbrecht <an...@orprovision.com>.
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.
Re: ActiveMQ 5 issues
Posted by Kevan Miller <ke...@gmail.com>.
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