You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "achintyag@gmail.com" <ac...@gmail.com> on 2016/06/10 02:26:20 UTC

Message is lost

We are using ActiveMQ 5.13.1 and ZooKeeper for levelDB and we have 3 activemq
nodes(n1,n2 and n3) that create a network of broker with masterslave
protocol. We post few messages and we see the master(n1) shows the message
count correctly, if we bring down the master node(n1) one of the slave
nodes(n2) becomes master and shows the message count correctly. Now if we
bring down the master node (n2) and bring up the node(n1) then slave2(n3)
becomes master but it shows message count is 0 i,e we loose all the
messages. That should not be happened in LevelDB store.

Can you explain what could be the wrong? Is there any bug?



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-is-lost-tp4712859.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message is lost

Posted by Tim Bain <tb...@alumni.duke.edu>.
What I mean is that you're using a fault-tolerant replicated datastore,
which means that the message can be considered successfully received by the
broker even if it's not written to all of the replicated stores.  By
shutting down all but one store and expecting that the messages will be
there, you're requiring n3 to have successfully received the messages, but
you've not described anything yet that proves that that actually happened.
So the first step is to prove that n3 actually got the messages; if it
didn't, the behavior you saw is expected and there's no bug.

I've never run LevelDB, so I don't have much direct experience here, but
I'd expect that you'd see files written to the data directory if n3 is
getting the messages.  The web console won't tell you anything useful here,
because it doesn't show any information about replication in a replicated
datastore.

Tim

On Sun, Jun 12, 2016 at 3:19 PM, achintyag@gmail.com <ac...@gmail.com>
wrote:

> Can you explain bit in details what do you mean by "n3 is actually
> receiving
> messages"? Or how I can test that n3 is receiving the messages or not. In
> ActiveMQ web console I see the Pending message is 0.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Message-is-lost-tp4712859p4712913.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Message is lost

Posted by "achintyag@gmail.com" <ac...@gmail.com>.
Can you explain bit in details what do you mean by "n3 is actually receiving
messages"? Or how I can test that n3 is receiving the messages or not. In
ActiveMQ web console I see the Pending message is 0.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-is-lost-tp4712859p4712913.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message is lost

Posted by Tim Bain <tb...@alumni.duke.edu>.
Do you know for sure that n3 is actually receiving messages?  The whole
point of LevelDB is that messages don't actually have to go everywhere
successfully, so make sure you test your assumption that all three nodes
are getting your messages.
On Jun 9, 2016 10:11 PM, "achintyag@gmail.com" <ac...@gmail.com> wrote:

> We are using ActiveMQ 5.13.1 and ZooKeeper for levelDB and we have 3
> activemq
> nodes(n1,n2 and n3) that create a network of broker with masterslave
> protocol. We post few messages and we see the master(n1) shows the message
> count correctly, if we bring down the master node(n1) one of the slave
> nodes(n2) becomes master and shows the message count correctly. Now if we
> bring down the master node (n2) and bring up the node(n1) then slave2(n3)
> becomes master but it shows message count is 0 i,e we loose all the
> messages. That should not be happened in LevelDB store.
>
> Can you explain what could be the wrong? Is there any bug?
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Message-is-lost-tp4712859.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>