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, 24 Aug 2010 18:42:00 GMT
Thanks, Gary, i appreciate the clarification. Still a couple of followup questions, with additional

1) B is analagous to the supermarket in section 10.2.1 of "ActiveMQ in Action", and A is the
backoffice. B needs to send messages back to A, in addition to receiving messages from A via
durable subscriptions. Like the supermarket/backoffice example, we may need to bring additional
Bs online in the future, and would like to do so without changing A's configuration. That's
why i asked about the duplex networkConnector on B. So, if i want messages to flow both directions
between A and B, is a single duplex networkConnector on B sufficient, or do i also need a
networkConnector on B?

2) By "selectors", do you include message selectors declared in MDB annotations (for example
@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "foo"))?

3) what do you mean by "coalesced" subscriptions? something like this? (this relates to question
#4 form my first message in ths sub-thread)

                    <queue physicalName="org.nwea.queues.central.>"/>
                    <topic physicalName="org.nwea.topics.>"/>
                    <queue physicalName="org.nwea.queues.central.>"/>
                    <topic physicalName="org.nwea.topics.>"/>

thanks again,

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/24/2010 03:11 AM, Gary Tully wrote:

A single non-duplex networkConnector on A is all that is required as
this will forward messages on demand (when it sees consumers on B
provided advisory support is not disabled) from A to B.

When B has a durable consumer, the proxy or forwarding consumer on A
will also be durable, with a well known subscription id that allows it
to outlive the durable consumer on B.

On a restart of A, this durable consumer will be auto recreated but
inactive, on a reconnect of a durable consumer to B, the corresponding
durable on B should be activated and messages should again flow.

To answer the questions:
1) that is over kill as there is no need for message flow from B to A.
2) yes. unless you want to use selectors, in which case subscriptions
cannot be coalesced
3) no, provided advisory support is enabled (the default)

On 24 August 2010 00:57, Joe Niski <><>
> As i continue to work on this problem and dig further into the AMQ docs, additional clarifying
questions have come up about network configuration in a store-and-forward scenario in which
the broker A publishes to topics on broker A, and broker B subscribes to identically-named
topics on broker B. i want to create durable subscriptions so the broker B will eventually
receive messages published when it's offline.
> 1) Is a single duplex networkConnector on broker B sufficient? (section 10.2.1 of "ActiveMQ
in Action" makes it seem like the answer is "yes".)
> 2) Is the "conduitSubscription" attribute required? (example 10.3 in "ActiveMQ in Action"
makes it seem like the answer is "yes".)
> 3) In the networkConnection on broker B, do i need to define "durableDestinations" for
the topics on broker A?
> 4) If the answer to (3) is "no", is it possible to point to the topics on broker A using
the ">" wildcard in the "<dynamicallyIncludedDestinations>" or "<staticallyIncludedDestinations>"
in broker B's networkConnector?
> thanks in advance,
> Joe
> 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.
> Cheers
> --
> Dejan Bosanac -
> Open Source Integration -
> ActiveMQ in Action -
> Blog -


Open Source Integration

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