[
https://issues.apache.org/activemq/browse/AMQ-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ying reopened AMQ-2070:
-----------------------
It seems that last time when the patch is applied, a line of code is merged
incorrectly. AMQ-2070-5.3.1.patch will fix that and make stopGracefully work
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
> Assignee: Rob Davies
> Fix For: 5.3.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.
