activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Niski <>
Subject Re: durable subscription problems
Date Tue, 17 Aug 2010 17:02:11 GMT
Will do, thanks for the reply.

Two additional bits of information:
- I should have said that I'm using AMQ 5.3.0, not 5.0.3
- here's the NPE stacktrace i'm seeing in my Remote broker activemq.log:

Aug-17 16:43:08,973 DEBUG [DemandForwardingBridge.serviceLocalException]:  The local Exception
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    at java.util.concurrent.ThreadPoolExecutor$

Joe Niski
IS Development |  NWEA

PHONE 503.212.3382  |  FAX 503.639.7873

NWEA.ORG<3D%22>  |  Partnering to Help All Kids Learn

On 08/17/2010 03:26 AM, Dejan Bosanac wrote:

Hi Joe,

this sounds like a bug. Did you tested it with some newer version of
ActiveMQ (as there was a lot of work in that area since 5.0.3)

Can you test newly released 5.4.0
and see if the problem still exists?

If it's still there, it would be great if you could raise a Jira
issue, ideally with a test case.

Dejan Bosanac -

Open Source Integration -
ActiveMQ in Action -
Blog -

On Tue, Aug 17, 2010 at 2:00 AM, Joe Niski <><>
> i have a network of 2 brokers, let's call them "Remote" and "Central", running on ActiveMQ
5.0.3, in a store-and-forward configuration. i inherited this setup, i did not design it,
but it seems like a generally solid configuration.
> On the Remote broker, there are topics (e.g. "org.nwea.topics.license") that have durable
subscriptions to topics of the same name on the Central broker. Messages that are published
to topics on the Central broker find their way to Remote really fast - as long as the Remote
is online when the message is published. Messages that are published when Remote is offline
are never picked up by the remote.
> i have a j2ee application that contains MDBs that are annotated to have durable subscriptions
to the topics on the Remote broker.
> The NetworkConnector configuration in the Remote broker's activemq.xml looks like this:
>        <networkConnectors>
>            <networkConnector name="${ApplianceID}"
>                              userName="${networkConnectorUserName}"
>                              password="${networkConnectorPassword}"
>                              uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
>                              duplex="true"
>                              dynamicOnly="true">
>                <dynamicallyIncludedDestinations>
>                    <queue physicalName="org.nwea.queues.central.>"/>
>                    <topic physicalName="org.nwea.topics.>"/>
>                </dynamicallyIncludedDestinations>
>                <staticallyIncludedDestinations>
>                    <queue physicalName="org.nwea.queues.central.>"/>
>                    <topic physicalName="org.nwea.topics.>"/>
>                </staticallyIncludedDestinations>
>            </networkConnector>
>        </networkConnectors>
> In reading through the book "ActiveMQ in Action" and reviewing the online docs at,
it seems that we should use the default setting for "dynamicOnly", "false" (the docs say "if
true, only forward messages if a consumer is active on the connected broker").
> However, when i set "dynamicOnly" to false, i see numerous startup errors and NullPointerExceptions
in the Remote activemq.log, and connection errors in Central's logs. The Remote log simply
> [DemandForwardingBridge.serviceLocalException]:  Network connection between vm://remotebroker.msg02.nweacolo.pvt#24
and ssl:// shutdown due to a local error: java.lang.NullPointerException
> With "dynamicOnly" set to true, the log shows that existing durable subscriptions are
reconnecting during startup.
> Playing with the "prefetchSize" and "networkTTL" attributes for <networkConnector>
on Remote (vaguely recommended in the docs) doesn't seem to have any effect.
> This seems very similar to this issue from February 2009:,
which didn't seem to get resolved.
> Any insight, recommendations, or help are most appreciated.
> --
> Joe Niski
> IS Development |  NWEA
> NWEA.ORG<3D%22>  |  Partnering to Help All Kids Learn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message