You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by shackman <f....@topdesk.com> on 2015/10/13 10:03:59 UTC
Persistent messages not moving from embedded broker to remote
broker
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.
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
here's a 7z file of the current version of my code:
https://drive.google.com/open?id=0Bwz8MAkPHsC6S25heC1fbGg1R2c
-----
Regards, Shackman
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703024.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
You're right, I went back and looked at the wrong line of your code. I was
looking for the URL you're using for the networkConnector, but found the
one for the producer instead. The networkConnector already has static, so
you can ignore this question entirely. Sorry for the confusion.
On Oct 15, 2015 8:08 AM, "shackman" <f....@topdesk.com> wrote:
> Tim Bain wrote
> > all the examples I'm used to seeing use either static:, failover:, or
> > masterslave: protocols to wrap the tcp: protocol for their
> > networkConnectors. Can you try using "static:(tcp:" + REMOTE_BROKER_URL
> +
> > ")" when creating your ActiveMQConnectionFactory and see if the behavior
> > changes?
>
> I'm not sure what you are asking me to do. That particular networkConnector
> works (publish2EmbeddedBroker = false). It's the other path that uses the
> embedded broker ("vm://" + EMBEDDED_BROKER_NAME) that's not working
> (publish2EmbeddedBroker = true). you will note that the embedded broker's
> networkConnection uses the format you specify.
>
> Perhaps copying this code and and running it locally might better
> demonstrate the problem? Is there a better way to share code than in a
> post,
> like an attached zip file?
>
> Here's the latest incarnations of PublishTopicTest and SubscribeTopicTest:
>
>
>
>
>
>
>
> Tim Bain wrote
> > Also, your current setup doesn't provide fault tolerance for the
> > standalone
> > broker itself. Do you need it to?
>
>
> thanks for hanging in here with me
>
>
>
>
> -----
> Regards, Shackman
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702998.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Tim Bain wrote
> all the examples I'm used to seeing use either static:, failover:, or
> masterslave: protocols to wrap the tcp: protocol for their
> networkConnectors. Can you try using "static:(tcp:" + REMOTE_BROKER_URL +
> ")" when creating your ActiveMQConnectionFactory and see if the behavior
> changes?
I'm not sure what you are asking me to do. That particular networkConnector
works (publish2EmbeddedBroker = false). It's the other path that uses the
embedded broker ("vm://" + EMBEDDED_BROKER_NAME) that's not working
(publish2EmbeddedBroker = true). you will note that the embedded broker's
networkConnection uses the format you specify.
Perhaps copying this code and and running it locally might better
demonstrate the problem? Is there a better way to share code than in a post,
like an attached zip file?
Here's the latest incarnations of PublishTopicTest and SubscribeTopicTest:
Tim Bain wrote
> Also, your current setup doesn't provide fault tolerance for the
> standalone
> broker itself. Do you need it to?
thanks for hanging in here with me
-----
Regards, Shackman
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702998.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
And the second one:
BTW, the configuration information you provided ruled out a couple of
possible explanations:
You're using duplex networkConnectors for both broker-to-broker
connections, so we don't have a problem where messages can only be
forwarded one way between a given pair of brokers.
Your client isn't using selectors that might not match your messages.
You don't appear to have disabled advisory messages on any of the brokers.
You're using the same topic name to publish and consume.
Thanks for providing it, and eliminating those possibilities. Hopefully
the answers to the questions I just asked will lead us in the right
direction.
One other thing: all the examples I'm used to seeing use either static:,
failover:, or masterslave: protocols to wrap the tcp: protocol for their
networkConnectors. Can you try using "static:(tcp:" + REMOTE_BROKER_URL +
")" when creating your ActiveMQConnectionFactory and see if the behavior
changes?
Also, your current setup doesn't provide fault tolerance for the standalone
broker itself. Do you need it to?
Tim
On Oct 15, 2015 6:52 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
> Either Nabble oe the mailing list itself appears to have not acknowledged
> either of my two previous replies from 36 hours ago in this thread, since
> they're not on the Nabble web page. That's annoying, especially since I
> wasn't given any notification that anything was wrong so I could fix it.
>
> Here's the first one:
>
> OK, so it seems like the standalone -> embedded-consumer connection is
> working fine (in that direction, at least), so we want to focus on the
> embedded-producer -> standalone path. While the producer is running, do
> you see the producer's embedded broker as a consumer on the advisory topic
> for consumers on your topic (ActiveMQ.Advisory.Consumer.TopicTest is the
> name I'd expect)? And do you see the standalone broker as a consumer on
> TopicTest in the producer's embedded broker? You're probably going to want
> to use JMX to answer those questions, not the web console.
>
> Tim
> On Oct 15, 2015 5:35 AM, "shackman" <f....@topdesk.com> wrote:
>
>> I was reading "ActiveMQ in Action" and got to the "PEER PROTOCOL" section
>> in
>> chapter 4. The "EXAMPLE USE OF THE PEER PROTOCOL" on page 93 reads
>> /exactly
>> /like the scenario I need to support. So I implemented a PeerGroup version
>> of my test.
>>
>> /I am having the exact same problem! All the connections are there, but no
>> messages get passed./
>>
>> I would think there's something wrong with my producer, but in the
>> previous
>> set of test classes, I can demonstrate that when the producer is connected
>> directly to a remote stand-alone router (i.e. a running instance of
>> activemq
>> "out-of-the-box"), the messages get through to the consumer. It's only
>> when
>> my producer tries to publish via the embedded broker to another broker
>> that
>> messages don't make it out.
>>
>> There's got to be something simple I must be missing.
>>
>> Here's my code. The first few classes are there to make it a bit easier to
>> write the core classes:
>>
>> IRunnable
>>
>> -------------------
>>
>> -------------------
>>
>> Utils
>>
>> -------------------
>>
>> -------------------
>>
>> Constants
>>
>> -------------------
>>
>> -------------------
>>
>> SubscribeTopicTest
>>
>> -------------------
>>
>> -------------------
>>
>> PublishTopicTest
>>
>> -------------------
>>
>> -------------------
>>
>> Here's the run log from the Publisher
>> -------------------
>>
>> -------------------
>>
>> Here's the run log from the Subscriber
>> -------------------
>>
>> -------------------
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702990.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Final update:
I finalized my proof-of-concept implementation of a messaging system using
AMQ that is:
* fault tolerant
* guaranteed delivery
* asynchronous (non-blocking application code)
* dynamically routed
* JNDI (JNP) discovered
Tim Bain wrote
> Yeah, that was what I found. But the fact that it wasn't documented on
> the
> wiki is a documentation failure on our part. I'll add it to the relevant
> pages when I find some time.
>
> In general, don't assume that the wiki thoroughly documents all topics.
> It's pretty good, but there are topics it never mentions that are
> documented elsewhere or not at all [snip]
I'm heading over to http://activemq.apache.org/contributing.html right now
to sign up to help with the
documentation. Perhaps adding a newbie's perspective to some of the wiki
pages will help.
-----
Regards, Shackman
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703404.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
Master/slave (http://activemq.apache.org/masterslave.html) is the standard
way to do it, so that a second broker takes over if the first goes down.
You have to make all your messages persistent if you want them available
after a failover, because the persistence store is how the slave figures
out what to do when it takes over.
There are three persistence store technologies: JDBC, KahaDB, and LevelDB.
JDBC is considerably slower than the other two and is used much less
frequently, and the primary reason I've heard for using it is when someone
wants the ability to look at what messages are in the store.
KahaDB is the default technology at the moment so it's widely used, but it
relies on a shared filesystem between the master and the slave hosts. If
you have a way to make your shared filesystem redundant (including both the
storage device and the network path to get to it), this could give you full
fault tolerance, or you could choose to live with having a single point of
failure in either of those.
LevelDB is meant to eliminate the shared filesystem while maintaining fault
tolerance by requiring writes to go to a quorum of the brokers before
considering it successful. But it's newer so there's a higher risk of bugs
(though it has seemed to become more stable in 5.12.x; I wouldn't even
consider running it on a previous version) and it'll require more hosts
(the recommended cluster size is three brokers instead of two, plus you'll
need to run three Zookeeper instances and I'm not sure if those can be run
on the same hosts or if they need their own). Also, recently there have
been a number of LevelDB questions going unanswered because I don't know
LevelDB well enough to answer them and no one who does has done so, so it
might be harder to get help with LevelDB right at the moment (but that's
always subject to change based on who is willing to donate their time to
answering questions on the list). But if you can live with the added
complexity, its purpose is to do exactly what you want.
Tim
On Oct 20, 2015 12:14 AM, "shackman" <f....@topdesk.com> wrote:
> Thanks for all the references. I'll start my reading schedule there.
>
>
> Tim Bain wrote
> > Also, your current setup doesn't provide fault tolerance for the
> > standalone broker itself. Do you need it to?
>
> In short, yes. Do you have a particular reference I can read about this
> topic? Or do you happen to have an xml file that is the "best practices"
> for
> fault tolerance?
>
> thanks again for all your help.
>
>
>
>
>
> -----
> Regards, Shackman
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703142.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Thanks for all the references. I'll start my reading schedule there.
Tim Bain wrote
> Also, your current setup doesn't provide fault tolerance for the
> standalone broker itself. Do you need it to?
In short, yes. Do you have a particular reference I can read about this
topic? Or do you happen to have an xml file that is the "best practices" for
fault tolerance?
thanks again for all your help.
-----
Regards, Shackman
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703142.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
On Oct 19, 2015 12:52 AM, "shackman" <f....@topdesk.com> wrote:
>
> Tim Bain wrote
> > When I Googled for how to set the JMX port of an embedded broker, here's
> > what I found: broker.getManagementContext().setConnectorPort(9999);
>
> Hint taken. I did google for this, but didn't get past the hits to the
> activemq site to find
>
http://stackoverflow.com/questions/6521898/how-do-i-specify-the-jmx-port-for-an-embedded-activemq-instance
>
> I need to change my search habits to look past the initial hits. Thanks
for
> finding this for me.
Yeah, that was what I found. But the fact that it wasn't documented on the
wiki is a documentation failure on our part. I'll add it to the relevant
pages when I find some time.
In general, don't assume that the wiki thoroughly documents all topics.
It's pretty good, but there are topics it never mentions that are
documented elsewhere or not at all (the slow consumer strategies jump to
mind here: the original AbortSlowConsumerStrategy doesn't have an
authoritative documentation page - you have to piece it together from
mailing list topics and references from Red Hat's documentation - while the
newer AbortSlowAckConsumerStrategy's authoritative documentation is on Tim
Bish's personal blog) and other topics that aren't very descriptive (the
JMX page's lack of definitions for attributes is the one that jumps to
mind). So definitely search beyond the official pages, into StackOverflow,
the mailing list archives, and blogs from people like Tim Bish, Christian
Posta, Bruce Snyder, and others, because the information might be out there
but not on the official wiki.
> Tim Bain wrote
> > And as I was typing that, I figured out what the problem is: your
> > networkConnectors are using the default networkTtl of 1, which means
that
> > messages can only be forwarded to one additional broker before being
> > consumed, and your topology requires two forwards. Set that to 2 and I
> > think your tests will work.
>
> That was it. I set both publisher and subscriber to networkTTL(10) and
> everything started working.
All of the wiki pages I saw that relate to embedded brokers talked about
them under the assumption that they'd be used as standalone brokers, but
having embedded brokers at the perimeter of a network of brokers is a very
valid use case and we should really do a better job of documenting how it
would work (and of pointing out that the default networkTTL value is going
to cause problems). I'll add that at some point when I get a chance.
> Thanks for all your help.
>
> I realize now that I need to read through the javax.jms api docs to get
> better familiar with all the tweaks.
>
>
>
> -----
> Regards, Shackman
> --
> View this message in context:
http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703107.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Tim Bain wrote
> When I Googled for how to set the JMX port of an embedded broker, here's
> what I found: broker.getManagementContext().setConnectorPort(9999);
Hint taken. I did google for this, but didn't get past the hits to the
activemq site to find
http://stackoverflow.com/questions/6521898/how-do-i-specify-the-jmx-port-for-an-embedded-activemq-instance
I need to change my search habits to look past the initial hits. Thanks for
finding this for me.
Tim Bain wrote
> And as I was typing that, I figured out what the problem is: your
> networkConnectors are using the default networkTtl of 1, which means that
> messages can only be forwarded to one additional broker before being
> consumed, and your topology requires two forwards. Set that to 2 and I
> think your tests will work.
That was it. I set both publisher and subscriber to networkTTL(10) and
everything started working.
Thanks for all your help.
I realize now that I need to read through the javax.jms api docs to get
better familiar with all the tweaks.
-----
Regards, Shackman
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4703107.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
When I Googled for how to set the JMX port of an embedded broker, here's
what I found: broker.getManagementContext().setConnectorPort(9999);
The existence of the advisory topic on the standalone broker isn't in
question; if it didn't get that far, your test where you publish directly
to the standalone broker wouldn't have worked. The question is whether the
subscription is getting to the producer broker.
And as I was typing that, I figured out what the problem is: your
networkConnectors are using the default networkTtl of 1, which means that
messages can only be forwarded to one additional broker before being
consumed, and your topology requires two forwards. Set that to 2 and I
think your tests will work.
Tim
Tim Bain wrote
> do you see the standalone broker as a consumer on TopicTest in the
> producer's embedded broker? You're probably going to want to use JMX to
> answer those questions, not the web console.
how do i configure the embedded brokers to use a different jmx port? the
first process to grab 1099 (the default) wins (which in this case is the
stand alone broker).
the other processes get:
WARN | Failed to start JMX connector Cannot bind to URL
[rmi://localhost:1099/jmxrmi]: javax.naming.NameAlreadyBoundException:
jmxrmi [Root exception is java.rmi.AlreadyBoundException: jmxrmi]. Will
restart management to re-create JMX connector, trying to remedy this issue.
i have 3 processes running on one host: central router, producer embedded
broker, and subscriber embedded broker
Tim Bain wrote
> While the producer is running, do you see the producer's embedded broker
> as a consumer on the advisory topic for consumers on your topic
> (ActiveMQ.Advisory.Consumer.TopicTest is the name I'd expect)?
to answer your question as best as i can. i am running the central router,
producer, and consumer processes and leaving them running:
1. start the central router
2. start the subscriber
3. start the publisher (which publishes 10 messages)
the activemq web console (showing the central router) shows
"ActiveMQ.Advisory.Consumer.Topic.CentralRouterTopicTest" (the topic name
was changed since i added another set of tests). jconsole confirms this.
Here is the producer log:
here is the subscriber log:
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702997.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Tim Bain wrote
> do you see the standalone broker as a consumer on TopicTest in the
> producer's embedded broker? You're probably going to want to use JMX to
> answer those questions, not the web console.
how do i configure the embedded brokers to use a different jmx port? the
first process to grab 1099 (the default) wins (which in this case is the
stand alone broker).
the other processes get:
WARN | Failed to start JMX connector Cannot bind to URL
[rmi://localhost:1099/jmxrmi]: javax.naming.NameAlreadyBoundException:
jmxrmi [Root exception is java.rmi.AlreadyBoundException: jmxrmi]. Will
restart management to re-create JMX connector, trying to remedy this issue.
i have 3 processes running on one host: central router, producer embedded
broker, and subscriber embedded broker
Tim Bain wrote
> While the producer is running, do you see the producer's embedded broker
> as a consumer on the advisory topic for consumers on your topic
> (ActiveMQ.Advisory.Consumer.TopicTest is the name I'd expect)?
to answer your question as best as i can. i am running the central router,
producer, and consumer processes and leaving them running:
1. start the central router
2. start the subscriber
3. start the publisher (which publishes 10 messages)
the activemq web console (showing the central router) shows
"ActiveMQ.Advisory.Consumer.Topic.CentralRouterTopicTest" (the topic name
was changed since i added another set of tests). jconsole confirms this.
Here is the producer log:
here is the subscriber log:
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702997.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
Either Nabble oe the mailing list itself appears to have not acknowledged
either of my two previous replies from 36 hours ago in this thread, since
they're not on the Nabble web page. That's annoying, especially since I
wasn't given any notification that anything was wrong so I could fix it.
Here's the first one:
OK, so it seems like the standalone -> embedded-consumer connection is
working fine (in that direction, at least), so we want to focus on the
embedded-producer -> standalone path. While the producer is running, do
you see the producer's embedded broker as a consumer on the advisory topic
for consumers on your topic (ActiveMQ.Advisory.Consumer.TopicTest is the
name I'd expect)? And do you see the standalone broker as a consumer on
TopicTest in the producer's embedded broker? You're probably going to want
to use JMX to answer those questions, not the web console.
Tim
On Oct 15, 2015 5:35 AM, "shackman" <f....@topdesk.com> wrote:
> I was reading "ActiveMQ in Action" and got to the "PEER PROTOCOL" section
> in
> chapter 4. The "EXAMPLE USE OF THE PEER PROTOCOL" on page 93 reads /exactly
> /like the scenario I need to support. So I implemented a PeerGroup version
> of my test.
>
> /I am having the exact same problem! All the connections are there, but no
> messages get passed./
>
> I would think there's something wrong with my producer, but in the previous
> set of test classes, I can demonstrate that when the producer is connected
> directly to a remote stand-alone router (i.e. a running instance of
> activemq
> "out-of-the-box"), the messages get through to the consumer. It's only when
> my producer tries to publish via the embedded broker to another broker that
> messages don't make it out.
>
> There's got to be something simple I must be missing.
>
> Here's my code. The first few classes are there to make it a bit easier to
> write the core classes:
>
> IRunnable
>
> -------------------
>
> -------------------
>
> Utils
>
> -------------------
>
> -------------------
>
> Constants
>
> -------------------
>
> -------------------
>
> SubscribeTopicTest
>
> -------------------
>
> -------------------
>
> PublishTopicTest
>
> -------------------
>
> -------------------
>
> Here's the run log from the Publisher
> -------------------
>
> -------------------
>
> Here's the run log from the Subscriber
> -------------------
>
> -------------------
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702990.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
I was reading "ActiveMQ in Action" and got to the "PEER PROTOCOL" section in
chapter 4. The "EXAMPLE USE OF THE PEER PROTOCOL" on page 93 reads /exactly
/like the scenario I need to support. So I implemented a PeerGroup version
of my test.
/I am having the exact same problem! All the connections are there, but no
messages get passed./
I would think there's something wrong with my producer, but in the previous
set of test classes, I can demonstrate that when the producer is connected
directly to a remote stand-alone router (i.e. a running instance of activemq
"out-of-the-box"), the messages get through to the consumer. It's only when
my producer tries to publish via the embedded broker to another broker that
messages don't make it out.
There's got to be something simple I must be missing.
Here's my code. The first few classes are there to make it a bit easier to
write the core classes:
IRunnable
-------------------
-------------------
Utils
-------------------
-------------------
Constants
-------------------
-------------------
SubscribeTopicTest
-------------------
-------------------
PublishTopicTest
-------------------
-------------------
Here's the run log from the Publisher
-------------------
-------------------
Here's the run log from the Subscriber
-------------------
-------------------
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702990.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote
broker
Posted by shackman <f....@topdesk.com>.
Greetings Tim.
thanks for your assistance.
here's my *publisher *code. it works fine with "publish2EmbeddedBroker =
false" and fails with "publish2EmbeddedBroker = true"
here's my *consumer *code. both poll and async modes work ok when there are
messages to be received.
i'm using activemq v5.12 right "out of the box" with no modifications to
*activemq.xml * and running it with ".\bin\activemq start" from a dos
command window:
Here's the process I use, from eclipse:
1. run the SubscriberTopicTest: it establishes a durable subscription, then
it shuts down
2. run the PublishTopicTest: if publishes messages, then it shuts down
3. run the SubscriberTopicTest: it establishes a durable subscription, reads
the messages, then it shuts down
i also monitor the central message router using the admin console at
http://localhost:8161/admin/. here's what i see using it:
1. during the subscription process, i see "NC:subscriberBroker:outbound
tcp://127.0.0.1:52591 true false" on the connections page, which goes away
after the subscription process shuts down.
2. during the publication process, i see "NC:publisherBroker:outbound
tcp://127.0.0.1:52593 true false" on the connections page
(publish2EmbeddedBroker == true), which goes away after the publication
process shuts down.
3. it ends with "TopicTest" on the topics page and an offline durable
subscription on the subcriver's page (but no messages enqueued with
"publish2EmbeddedBroker = true"). all other combinations enqueue and dequeue
ok.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-not-moving-from-embedded-broker-to-remote-broker-tp4702884p4702896.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Persistent messages not moving from embedded broker to remote broker
Posted by Tim Bain <tb...@alumni.duke.edu>.
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....@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.
>