[ 
https://issues.apache.org/activemq/browse/AMQ-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ying updated AMQ-2070:
----------------------

    Description: 
There are a few issues to stop activemq
1. using jconsole and call broker.stop(), the java process of activemq will not 
quit, the root cause is when jetty is configured using xbean in activemq.xml, 
the broker.stop() does not stop jetty server so the java process will not quit, 
however the web admin will not work after broker.stop() and will display jsp 
exceptions.
2. the current activemq-console code which activemq-admin is using to do stop 
broker is calling terminateJVM and does not handle exceptions thrown
3. we have a use case when we stop a broker, we don't want any pending messages 
stuck in the broker, because it requires us to restart the broker immediately 
to not to lose those pending messages.It will be a problem if in real world we 
cannot restart it right away and those pending messages are critical. 
The solution we thought is as follows:
What we want is to use the current network of brokers forwarding mechanism to 
forward those pending messages to other broker which has a related consumer, 
then stop the broker completely and we don't need to restart the stopped broker 
right away. for example, we have a network of two brokers, A, and B, the 
client(producer/consumer) is using failover://(tcp:brokerA:port1, 
tcp:brokerB:port1), then when we want to stop A and it has 10 pending messages, 
we want stop A's transport that the client is connecting to, so client will 
failover to broker B, then 10 pending messages will be forwarded to broker B, 
then we can stop the broker A completely.

To address the above issues, attached are two patches, one for activemq-core 
and one for activemq-console, both patches are based on tags/activemq-5.2.0 
please review them and I will appreciate if it can be applied to trunk. If you 
have any question regarding these changes, please let me know. Thank you.

With the patches:

Here is a sample usage:
./activemq-admin stopGracefully --connectorName ssl --queueName test*? 
--timeout 120 --pollInterval 20 --jmxurl 
service:jmx:rmi:///jndi/rmi://localhost:3616/jmxrmi

this command will stop connector ssl, and it will check queues starting with 
test (queueName takes regex) to make sure they have no pending messages then 
stop the broker. It will check the queuesize every 20 seconds and timeout in 
120 seconds. If after timeout, there are still pending messages in the queues, 
it will not stop the broker and it will need manual check to stop the broker 
properly.

ADDED: 
1. the patches fix more issues for stopping the broker. if broker starts as 
master and waitForslave, stop will not let the java quit the process. Also if 
slave is started first and use failover to talk to the master, you can also 
stop it before it establish the connection with the master.

2. added to use localProcessId to get jmxurl, that way, activemq-admin can 
access jmx as a local jconsole, without jmxuser and jmxpassword, while remote 
jconsole still needs authentication when it is turned on. for this you need 
-Dcom.sun.management.jmxremote when starting activemq

There is a known issue of jmx rmi is two ports, one can be configured and the 
other is using random ports when a remote jconsole connects. this is not 
acceptable in a firewall environment. If concerned, please check my other post 
http://www.nabble.com/JMX-remote-managmentContext-and-firewall-to21969017.html 
you can use a custom agent to be able to configure two fixed ports.


  was:
There are a few issues to stop activemq
1. using jconsole and call broker.stop(), the java process of activemq will not 
quit, the root cause is when jetty is configured using xbean in activemq.xml, 
the broker.stop() does not stop jetty server so the java process will not quit, 
however the web admin will not work after broker.stop() and will display jsp 
exceptions.
2. the current activemq-console code which activemq-admin is using to do stop 
broker is calling terminateJVM and does not handle exceptions thrown
3. we have a use case when we stop a broker, we don't want any pending messages 
stuck in the broker, because it requires us to restart the broker immediately 
to not to lose those pending messages.It will be a problem if in real world we 
cannot restart it right away and those pending messages are critical. 
The solution we thought is as follows:
What we want is to use the current network of brokers forwarding mechanism to 
forward those pending messages to other broker which has a related consumer, 
then stop the broker completely and we don't need to restart the stopped broker 
right away. for example, we have a network of two brokers, A, and B, the 
client(producer/consumer) is using failover://(tcp:brokerA:port1, 
tcp:brokerB:port1), then when we want to stop A and it has 10 pending messages, 
we want stop A's transport that the client is connecting to, so client will 
failover to broker B, then 10 pending messages will be forwarded to broker B, 
then we can stop the broker A completely.

To address the above issues, attached are two patches, one for activemq-core 
and one for activemq-console, both patches are based on tags/activemq-5.2.0 
please review them and I will appreciate if it can be applied to trunk. If you 
have any question regarding these changes, please let me know. Thank you.

With the patches:

Here is a sample usage:
./activemq-admin stopGracefully --connectorName ssl --queueName test*? 
--timeout 120 --pollInterval 20 --jmxurl 
service:jmx:rmi:///jndi/rmi://localhost:3616/jmxrmi

this command will stop connector ssl, and it will check queues starting with 
test (queueName takes regex) to make sure they have no pending messages then 
stop the broker. It will check the queuesize every 20 seconds and timeout in 
120 seconds. If after timeout, there are still pending messages in the queues, 
it will not stop the broker and it will need manual check to stop the broker 
properly.





> activemq process does not exit after stop() and other stop related issue
> ------------------------------------------------------------------------
>
>                 Key: AMQ-2070
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2070
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.2.0
>         Environment: windows xp and solaris
>            Reporter: ying
>         Attachments: patchActiveMQConsole5.2.0, patchActiveMQCore5.2.0, 
> StopGracefullyCommand.java
>
>
> There are a few issues to stop activemq
> 1. using jconsole and call broker.stop(), the java process of activemq will 
> not quit, the root cause is when jetty is configured using xbean in 
> activemq.xml, the broker.stop() does not stop jetty server so the java 
> process will not quit, however the web admin will not work after 
> broker.stop() and will display jsp exceptions.
> 2. the current activemq-console code which activemq-admin is using to do stop 
> broker is calling terminateJVM and does not handle exceptions thrown
> 3. we have a use case when we stop a broker, we don't want any pending 
> messages stuck in the broker, because it requires us to restart the broker 
> immediately to not to lose those pending messages.It will be a problem if in 
> real world we cannot restart it right away and those pending messages are 
> critical. 
> The solution we thought is as follows:
> What we want is to use the current network of brokers forwarding mechanism to 
> forward those pending messages to other broker which has a related consumer, 
> then stop the broker completely and we don't need to restart the stopped 
> broker right away. for example, we have a network of two brokers, A, and B, 
> the client(producer/consumer) is using failover://(tcp:brokerA:port1, 
> tcp:brokerB:port1), then when we want to stop A and it has 10 pending 
> messages, we want stop A's transport that the client is connecting to, so 
> client will failover to broker B, then 10 pending messages will be forwarded 
> to broker B, then we can stop the broker A completely.
> To address the above issues, attached are two patches, one for activemq-core 
> and one for activemq-console, both patches are based on tags/activemq-5.2.0 
> please review them and I will appreciate if it can be applied to trunk. If 
> you have any question regarding these changes, please let me know. Thank you.
> With the patches:
> Here is a sample usage:
> ./activemq-admin stopGracefully --connectorName ssl --queueName test*? 
> --timeout 120 --pollInterval 20 --jmxurl 
> service:jmx:rmi:///jndi/rmi://localhost:3616/jmxrmi
> this command will stop connector ssl, and it will check queues starting with 
> test (queueName takes regex) to make sure they have no pending messages then 
> stop the broker. It will check the queuesize every 20 seconds and timeout in 
> 120 seconds. If after timeout, there are still pending messages in the 
> queues, it will not stop the broker and it will need manual check to stop the 
> broker properly.
> ADDED: 
> 1. the patches fix more issues for stopping the broker. if broker starts as 
> master and waitForslave, stop will not let the java quit the process. Also if 
> slave is started first and use failover to talk to the master, you can also 
> stop it before it establish the connection with the master.
> 2. added to use localProcessId to get jmxurl, that way, activemq-admin can 
> access jmx as a local jconsole, without jmxuser and jmxpassword, while remote 
> jconsole still needs authentication when it is turned on. for this you need 
> -Dcom.sun.management.jmxremote when starting activemq
> There is a known issue of jmx rmi is two ports, one can be configured and the 
> other is using random ports when a remote jconsole connects. this is not 
> acceptable in a firewall environment. If concerned, please check my other 
> post 
> http://www.nabble.com/JMX-remote-managmentContext-and-firewall-to21969017.html
>  you can use a custom agent to be able to configure two fixed ports.

-- 
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