You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Aaron Digulla (JIRA)" <ji...@apache.org> on 2007/10/18 15:44:23 UTC
[jira] Created: (AMQ-1470) There is no way to cleanly shutdown
ActiveMQ
There is no way to cleanly shutdown ActiveMQ
--------------------------------------------
Key: AMQ-1470
URL: https://issues.apache.org/activemq/browse/AMQ-1470
Project: ActiveMQ
Issue Type: Improvement
Components: Connector, Test Cases, Transport
Affects Versions: 4.1.1
Reporter: Aaron Digulla
I need to test and build a highly reliable AMQ application. I'm using JUnit for my test cases and Tomcat as webserver.
My problem is that after closing all connections and sessions, there are still many threads hanging around. This makes it impossible to undeploy the webapp in Tomcat and it makes test cases unreliable since I can't guarantee that the environment is clean.
So far, I have identifier the following issues:
- If FailoverTransport hangs in oneway() because the AMQ server is not running, there is no way to stop it. Sending the thread an interrupt will only cause an endless loop (missing break in catch of InterruptedException after "Waiting for transport to reconnect.").
- Even if I interrupt the thread, it's not sure what it will do next. It might try to reconnect the next moment because I can't dispose the connection because of a deadlock in ActiveMQConnection (see http://www.nabble.com/Reliably-starting-and-stopping-of-a-producer-consumer-tf4600635s2354.html#a13229979).
- After fixing those two, I see two thread pools left: Scheduler.clockDaemon and ActiveMQConnectionFactory.DEFAULT_CONNECTION_EXECUTOR. Both won't stop running which means that there will be references to AMQ so Tomcat can't undeploy the application.
I tried to call shutdownNow() on the executors which gets me halfway where I need to be but now, the tests fail because when I try to create the next connection after a shutdown, the executors are in an illegal state (TERMINATED instead of RUNNING). My solution here was to kill the executors and recreate them in my tests.
But there should be a better way to do this :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-1470) There is no way to cleanly shutdown
ActiveMQ
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1470.
-----------------------------
Fix Version/s: 5.2.0
Resolution: Fixed
Fixed applied in SVN revision 669512
> There is no way to cleanly shutdown ActiveMQ
> --------------------------------------------
>
> Key: AMQ-1470
> URL: https://issues.apache.org/activemq/browse/AMQ-1470
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Connector, Test Cases, Transport
> Affects Versions: 4.1.1
> Reporter: Aaron Digulla
> Assignee: Rob Davies
> Fix For: 5.2.0
>
>
> I need to test and build a highly reliable AMQ application. I'm using JUnit for my test cases and Tomcat as webserver.
> My problem is that after closing all connections and sessions, there are still many threads hanging around. This makes it impossible to undeploy the webapp in Tomcat and it makes test cases unreliable since I can't guarantee that the environment is clean.
> So far, I have identifier the following issues:
> - If FailoverTransport hangs in oneway() because the AMQ server is not running, there is no way to stop it. Sending the thread an interrupt will only cause an endless loop (missing break in catch of InterruptedException after "Waiting for transport to reconnect.").
> - Even if I interrupt the thread, it's not sure what it will do next. It might try to reconnect the next moment because I can't dispose the connection because of a deadlock in ActiveMQConnection (see http://www.nabble.com/Reliably-starting-and-stopping-of-a-producer-consumer-tf4600635s2354.html#a13229979).
> - After fixing those two, I see two thread pools left: Scheduler.clockDaemon and ActiveMQConnectionFactory.DEFAULT_CONNECTION_EXECUTOR. Both won't stop running which means that there will be references to AMQ so Tomcat can't undeploy the application.
> I tried to call shutdownNow() on the executors which gets me halfway where I need to be but now, the tests fail because when I try to create the next connection after a shutdown, the executors are in an illegal state (TERMINATED instead of RUNNING). My solution here was to kill the executors and recreate them in my tests.
> But there should be a better way to do this :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-1470) There is no way to cleanly shutdown
ActiveMQ
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1470:
-------------------------------
Assignee: Rob Davies
> There is no way to cleanly shutdown ActiveMQ
> --------------------------------------------
>
> Key: AMQ-1470
> URL: https://issues.apache.org/activemq/browse/AMQ-1470
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Connector, Test Cases, Transport
> Affects Versions: 4.1.1
> Reporter: Aaron Digulla
> Assignee: Rob Davies
>
> I need to test and build a highly reliable AMQ application. I'm using JUnit for my test cases and Tomcat as webserver.
> My problem is that after closing all connections and sessions, there are still many threads hanging around. This makes it impossible to undeploy the webapp in Tomcat and it makes test cases unreliable since I can't guarantee that the environment is clean.
> So far, I have identifier the following issues:
> - If FailoverTransport hangs in oneway() because the AMQ server is not running, there is no way to stop it. Sending the thread an interrupt will only cause an endless loop (missing break in catch of InterruptedException after "Waiting for transport to reconnect.").
> - Even if I interrupt the thread, it's not sure what it will do next. It might try to reconnect the next moment because I can't dispose the connection because of a deadlock in ActiveMQConnection (see http://www.nabble.com/Reliably-starting-and-stopping-of-a-producer-consumer-tf4600635s2354.html#a13229979).
> - After fixing those two, I see two thread pools left: Scheduler.clockDaemon and ActiveMQConnectionFactory.DEFAULT_CONNECTION_EXECUTOR. Both won't stop running which means that there will be references to AMQ so Tomcat can't undeploy the application.
> I tried to call shutdownNow() on the executors which gets me halfway where I need to be but now, the tests fail because when I try to create the next connection after a shutdown, the executors are in an illegal state (TERMINATED instead of RUNNING). My solution here was to kill the executors and recreate them in my tests.
> But there should be a better way to do this :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-1470) There is no way to cleanly shutdown
ActiveMQ
Posted by "james defelice (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44124#action_44124 ]
james defelice commented on AMQ-1470:
-------------------------------------
Any idea if this will be fixed for the 4.x release? If so, what does the timeline look like?
> There is no way to cleanly shutdown ActiveMQ
> --------------------------------------------
>
> Key: AMQ-1470
> URL: https://issues.apache.org/activemq/browse/AMQ-1470
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Connector, Test Cases, Transport
> Affects Versions: 4.1.1
> Reporter: Aaron Digulla
> Assignee: Rob Davies
> Fix For: 5.2.0
>
>
> I need to test and build a highly reliable AMQ application. I'm using JUnit for my test cases and Tomcat as webserver.
> My problem is that after closing all connections and sessions, there are still many threads hanging around. This makes it impossible to undeploy the webapp in Tomcat and it makes test cases unreliable since I can't guarantee that the environment is clean.
> So far, I have identifier the following issues:
> - If FailoverTransport hangs in oneway() because the AMQ server is not running, there is no way to stop it. Sending the thread an interrupt will only cause an endless loop (missing break in catch of InterruptedException after "Waiting for transport to reconnect.").
> - Even if I interrupt the thread, it's not sure what it will do next. It might try to reconnect the next moment because I can't dispose the connection because of a deadlock in ActiveMQConnection (see http://www.nabble.com/Reliably-starting-and-stopping-of-a-producer-consumer-tf4600635s2354.html#a13229979).
> - After fixing those two, I see two thread pools left: Scheduler.clockDaemon and ActiveMQConnectionFactory.DEFAULT_CONNECTION_EXECUTOR. Both won't stop running which means that there will be references to AMQ so Tomcat can't undeploy the application.
> I tried to call shutdownNow() on the executors which gets me halfway where I need to be but now, the tests fail because when I try to create the next connection after a shutdown, the executors are in an illegal state (TERMINATED instead of RUNNING). My solution here was to kill the executors and recreate them in my tests.
> But there should be a better way to do this :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.