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

Rob Davies resolved AMQ-2070.
-----------------------------

    Fix Version/s: 5.4.0
                       (was: 5.3.0)
       Resolution: Fixed

Fixed by SVN revision 963104

> 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
>            Assignee: Rob Davies
>             Fix For: 5.4.0
>
>         Attachments: AMQ-2070-5.3.1.patch, 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