You should post your consumer code and your broker config. It's possible to set settings in both of them that would result in the behavior you describe, so I want to make sure everything is OK there.
Can you confirm that you see a connection from the embedded broker to the standalone broker when you look at JMX on the standalone broker? Also, can you confirm that the name of the topic to which the producer is publishing matches the name of the topic to which the consumer is subscribing? A mismatch there might be easy to overlook and would explain the behavior you're seeing even if you configured everything else correctly. Let's double-check that before we sink too much time into other possibilities. You should also enable JMX on the publisher's embedded broker and use it see whether the subscription on the topic is making it to the embedded broker. Knowing that will help figure out where to go next. Tim On Oct 13, 2015 2:14 AM, "shackman" <f.shackelf...@topdesk.com> wrote: > Greetings All. > > As a new comer to ActiveMQ, i'm a bit stumped on how to get something to > work. I would be most grateful for your insights into how to make this > work. > > We are trying to use ActiveMQ to implement the requirements seen below. > > We are using Java configuration, not XML configuration. We have tried to > implement the above using the following: > • Publisher has an embedded broker with a network connector to the > Message > Router > • Subscriber as an embedded broker with a network connector to the > Message > Router > Our results have been: > • Subscriber subscribes with the embedded broker and the Message > router > shows the subscription (great!) > • Producer publishes to embedded broker, but the Message router > doesn’t > receive the messages (why?) > > > Specifications > > 1. Fault tolerant > 2. Guaranteed delivery (Time to delivery is out of scope) > 3. Three “actors” > 1. Topic Publisher > 2. Topic Subscriber > 3. Message router > 4. Each actor runs in its own process on a host somewhere > 5. Non-blocking > 6. All message paths are dynamic; that is, the Message router has no > knowledge of publishers, topics, or subscribers until they actually publish > or subscribe > 7. Interface must be JMS. Implementation can be anything that meets > our > needs (we chose activemq because it looks promising but we are not married > to it) > > Use cases > > > #1 Clean path > > Goal: > > To demonstrate > • How it appears to work at all times > Set up: > > • All actor processes are running > Steps > > 1. Subscriber registers a persistent subscription with its embedded > broker > for topic A > 2. Publisher sends a persistent message to its embedded broker for > topic A > 3. Subscriber receives the message from its embedded broker > > #2 Non-blocking guaranteed delivery > > Goal: > > To demonstrate > • That this operates just as if it were the clean path (iow: all > actors are > unaware of the fault), only the timing is delayed. > • Guaranteed delivery > • Non-blocking (async) > Set up: > > • All actor processes are running > • Message router is inaccessible to all other actors (to simulate a > fault) > Steps > > 1. Subscriber registers a persistent subscription with its embedded > broker > for topic A and continues with other tasks > 2. Message router becomes accessible to the other actors > a. Subscriber’s registration is received by the Message router > 3. Message router becomes inaccessible to the other actors > 4. Publisher sends persistent messages to its embedded broker for > topic A > and continues with other tasks > 5. Message router becomes accessible to the other actors > a. Publisher’s message backlog is received by the Message > router > b. Subscriber’s topic A messages are read from its embedded > broker (as > received from the Message router) > > > Here's the core of my publisher code: > > > > here's the output log: > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
