[jira] Resolved: (AMQ-2070) activemq process does not exit after stop() and other stop related issue

["Rob Davies (JIRA)" <ji...@apache.org>]

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