activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ying (JIRA)" <>
Subject [jira] Reopened: (AMQ-2070) activemq process does not exit after stop() and other stop related issue
Date Thu, 08 Apr 2010 17:51:08 GMT


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:
>             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,
> 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.
> 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 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
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.

View raw message