You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "William Lam (JIRA)" <ji...@apache.org> on 2007/10/05 17:16:31 UTC
[jira] Created: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
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
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.
[jira] Issue Comment Edited: (AMQ-1447) Broker cannot shutdown
cleanly due to hanging non-daemon threads.
Posted by "Scott Emmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58343#action_58343 ]
Scott Emmons edited comment on AMQ-1447 at 3/19/10 10:22 PM:
-------------------------------------------------------------
This still appears to be an issue in 5.3.0. I am using activemq-core-5.3.0.jar, but ActiveMQ Transport threads are not daemon:
"ActiveMQ Transport: tcp://xyz/127.0.0.1:61616" prio=1 tid=0x6a651420 nid=0x6d62 runnable [0x69ef8000..0x69ef9000]
Unfortunately this results in not being able to bring Tomcat application servers down gracefully.
Note that the ActiveMQ Scheduler thread is setup correctly, so this appears specific to the Transport code:
"ActiveMQ Scheduler" daemon prio=1 tid=0x0973deb8 nid=0x6d68 in Object.wait() [0x697fe000..0x697fed80]
NOTE: Environment is linux 2.6.31-19-generic-pae #56-Ubuntu SMP
EDIT: Whoops, My note turned into a link due to square brackets. Fixed...
was (Author: scotte):
This still appears to be an issue in 5.3.0. I am using activemq-core-5.3.0.jar, but ActiveMQ Transport threads are not daemon:
"ActiveMQ Transport: tcp://scotte.mygazoo.com/127.0.0.1:61616" prio=1 tid=0x6a651420 nid=0x6d62 runnable [0x69ef8000..0x69ef9000]
Unfortunately this results in not being able to bring Tomcat application servers down gracefully.
Note that the ActiveMQ Scheduler thread is setup correctly, so this appears specific to the Transport code:
"ActiveMQ Scheduler" daemon prio=1 tid=0x0973deb8 nid=0x6d68 in Object.wait() [0x697fe000..0x697fed80]
[NOTE: Environment is linux 2.6.31-19-generic-pae #56-Ubuntu SMP]
> 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.
[jira] Commented: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
Posted by "Julien HENRY (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62036#action_62036 ]
Julien HENRY commented on AMQ-1447:
-----------------------------------
Thanks for the workaround. Note that for me, appending ?daemon=true was enough to have a clean shutdown. No need to use failover: and maxReconnectDelay (I'm running activemq 5.4.1).
> 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.
[jira] Issue Comment Edited: (AMQ-1447) Broker cannot shutdown
cleanly due to hanging non-daemon threads.
Posted by "Scott Emmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58343#action_58343 ]
Scott Emmons edited comment on AMQ-1447 at 3/19/10 10:10 PM:
-------------------------------------------------------------
This still appears to be an issue in 5.3.0. I am using activemq-core-5.3.0.jar, but ActiveMQ Transport threads are not daemon:
"ActiveMQ Transport: tcp://scotte.mygazoo.com/127.0.0.1:61616" prio=1 tid=0x6a651420 nid=0x6d62 runnable [0x69ef8000..0x69ef9000]
Unfortunately this results in not being able to bring Tomcat application servers down gracefully.
Note that the ActiveMQ Scheduler thread is setup correctly, so this appears specific to the Transport code:
"ActiveMQ Scheduler" daemon prio=1 tid=0x0973deb8 nid=0x6d68 in Object.wait() [0x697fe000..0x697fed80]
[NOTE: Environment is linux 2.6.31-19-generic-pae #56-Ubuntu SMP]
was (Author: scotte):
This still appears to be an issue in 5.3.0. I am using activemq-core-5.3.0.jar, but ActiveMQ Transport threads are not daemon:
"ActiveMQ Transport: tcp://scotte.mygazoo.com/127.0.0.1:61616" prio=1 tid=0x6a651420 nid=0x6d62 runnable [0x69ef8000..0x69ef9000]
Unfortunately this results in not being able to bring Tomcat application servers down gracefully.
Note that the ActiveMQ Scheduler thread is setup correctly, so this appears specific to the Transport code:
"ActiveMQ Scheduler" daemon prio=1 tid=0x0973deb8 nid=0x6d68 in Object.wait() [0x697fe000..0x697fed80]
> 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.
[jira] Commented: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
Posted by "Marshall Pierce (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52736#action_52736 ]
Gary Tully commented on AMQ-1447:
---------------------------------
on trunk at least, adding a query parameter of daemon=true to the networkConnector urls should eliminate this if it is still a daemon thread.
> 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.4.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.
[jira] Reopened: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
Posted by "Scott Emmons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Emmons reopened AMQ-1447:
-------------------------------
This still appears to be an issue in 5.3.0. I am using activemq-core-5.3.0.jar, but ActiveMQ Transport threads are not daemon:
"ActiveMQ Transport: tcp://scotte.mygazoo.com/127.0.0.1:61616" prio=1 tid=0x6a651420 nid=0x6d62 runnable [0x69ef8000..0x69ef9000]
Unfortunately this results in not being able to bring Tomcat application servers down gracefully.
Note that the ActiveMQ Scheduler thread is setup correctly, so this appears specific to the Transport code:
"ActiveMQ Scheduler" daemon prio=1 tid=0x0973deb8 nid=0x6d68 in Object.wait() [0x697fe000..0x697fed80]
> 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.
[jira] Resolved: (AMQ-1447) Broker cannot shutdown cleanly due to
hanging non-daemon threads.
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1447.
-----------------------------
Resolution: Fixed
Fix Version/s: (was: 5.4.0)
5.3.0
> 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.