[ 
https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58344#action_58344
 ] 

Marshall Pierce commented on AMQ-1447:
--------------------------------------

Scott, I was able to get tomcat to shutdown cleanly using this configuration:

<Resource name="jms/queueConnectionFactory"
auth="Container" 
type="org.apache.activemq.ActiveMQConnectionFactory" 
factory="org.apache.activemq.jndi.JNDIReferenceFactory" 
brokerURL="failover:(tcp://127.0.0.1:61616?daemon=true)?maxReconnectDelay=5000" 
/>

> Broker cannot shutdown cleanly due to hanging non-daemon threads.
> -----------------------------------------------------------------
>
>                 Key: AMQ-1447
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1447
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.1.1
>         Environment: Windows XP, JDK 1.4.2
>            Reporter: William Lam
>             Fix For: 5.3.0
>
>
> Running with an embedded broker inside an application, the application failed 
> to shutdown cleanly due to some hanging ActiveMQ non-daemon threads, sample 
> stacktace as below.
> "ActiveMQ Transport: tcp://oat-dualcore113/172.17.0.113:61616" prio=5 
> tid=0x041b8658 nid=0x12f4 in Object.wait() [6c7f000..6c7fdc0]
>       at java.lang.Object.wait(Native Method)
>       - waiting on <0x168c0490> (a 
> edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>       at java.lang.Object.wait(Object.java:429)
>       at 
> edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:178)
>       - locked <0x168c0490> (a 
> edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>       at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport.java:842)
>       at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:332)
>       at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport.java:131)
>       at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:95)
>       at 
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
>       at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:133)
>       at 
> org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
>       at 
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
>       at 
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>       at java.lang.Thread.run(Thread.java:534)
> It may be caused by other invalid broker connection attempts (not sure how) 
> and TcpTransport is waiting for a successful connection to the remote broker. 
>  
> Various ways to workaround that failed,
> - TcpTransport is not being exposed to the application by any means (unlike 
> ActiveMQConnection - even though it is package not public)
> - no means to set the TcpTransport as daemon since it is set on the 
> constructor
> Have to put in some 'custom' code in the application to find all 'ActiveMQ' 
> non-daemon threads and stop() them.  Note interrupt() won't work since 
> InterruptedException was ignored.
> I am using the default multicast for broker discovery  (tried that with other 
> multicast address, same problem)
>     <networkConnectors>
>       <networkConnector name="default" uri="multicast://default" 
> failover="false"/>
>     </networkConnectors>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to