Systematic trial-and-error in configuring the networkConnector lead us
to a solution on this.
either of the following configurations work flawlessly:
The element in the configuration we
inherited prevented durable subscriptions from getting established
altogether.
Setting dyn
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 cons
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 dur
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 know
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
Schema validation is the default with spring 3. Elements in the broker
sequence must follow alphabetical ordering 2 validate.
On Tuesday, August 17, 2010, Joe Niski wrote:
> Greetings again, Dejan:
>
> I tried setting up another Remote broker using the 5.40 release, just
> dropping my existing c
Greetings again, Dejan:
I tried setting up another Remote broker using the 5.40 release, just dropping
my existing configuration files into place.
I'm getting this parsing error on startup:
ERROR: java.lang.RuntimeException: Failed to execute start task. Reason:
org.springframework.beans.factor
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 was:
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 stil