Am I right in understanding that you're no longer having the problem from your first email, and the problem from yesterday is the only one?
When you stop the broker, how are you stopping it? If you're doing kill -9, that doesn't gracefully shut down the TCP connections, so the behavior can be different than if you issue a stop at the command prompt. It should still work eventually (and since it's not working for you, then it's either a bug in our code or a bug in yours), but be aware that the clean shutdown case will be faster than the hard kill case, so don't expect identical behavior between the two cases. Can you post your consumer configuration/code so we can see if there is something obvious that might explain what you're seeing? Also, it sounds like you took a thread dump when this was happening; are you able to post it? Also, is this consistently reproducible? And what happens if you start A and stop B once you're in this state? Tim On Sep 19, 2016 6:25 PM, "akhil" <akh...@gmail.com> wrote: > Hi , I am having the same type of issue but with the different > configuration. > I have two brokers which are not in network but i am using producer and > consumer with two different threads in my local and trying to hit 10k > messages and consume it from second thread. I am using the shared file > storage mount for the kaha db mount.One of the broker is acting as a master > any any point of time and the other one is slave. I have started my test > with Broker A as master and producer is sending out messages and consumer > started listening to it.. to add the complexity i have turned of the Broker > A and the lock got acquired by Broker B and it is now new master. Producer > got reconnected to master but consumer is failing and invoked the > inactivity > monitor and i have observed the TIME_WAIT thread block of connection broker > of consumer thread and it never ever reconnected to the new master ? > > Producer no issues in regards to the reconnection in failover scenario but > consumer does ..any one any suggestions ..is it something real bug with a > race condition or some thing we need to put it in the consumer code to > avoid > this failure ? > > Thanks, > Akhil. > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/JMS-exception-during-the-Failover-tp4716047p4716642.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
