A single duplex connector on either end will work. It will create a forwarding bridge in both directions.
Yes, selectors are JMS message selectors. The only think to note is that with conduit subscriptions (where multiple consumers for a destination are considered by the bridge to be a single consumer) selectors are not honored by the bridge. All messages will be forwarded to the other broker where the selector will have effect, which can leave some unmatched messaged dangling on that broker. If you don't want that, then you need to disable conduit subscriptions and have each subscription with its relevant selector be mapped independently by the forwarding bridge. If the selectors overlap there will be duplicate messages. On 24 August 2010 19:42, Joe Niski <joe.ni...@nwea.org> wrote: > Thanks, Gary, i appreciate the clarification. Still a couple of followup > questions, with additional info: > > 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) > > <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> > > thanks again, > Joe > > > Joe Niski > IS Development | NWEA > > PHONE 503.212.3382 | FAX 503.639.7873 > > NWEA.ORG<3D%22http://www.nwea.org/%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 > <joe.ni...@nwea.org><mailto:joe.ni...@nwea.org> wrote: >> 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%22http://www.nwea.org/%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 >> http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/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 - http://twitter.com/dejanb >> >> Open Source Integration - http://fusesource.com/ >> ActiveMQ in Action - http://www.manning.com/snyder/ >> Blog - http://www.nighttale.net >> >> >> > > > > -- > http://blog.garytully.com > > Open Source Integration > http://fusesource.com > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
