Okay, I think I found the problem. There is a race condition between the time the message is set with the broker sequence number (RegionBroker.java in send method), and the time it is actually put in the database (DefaultJDBCAdapter.java in doAddMessage method).
I have seen that sometimes message with higher sequence number are put in database before a lower sequence number. For example: 386 is put in the database before 385. If it is happening when JDBCMessageStore is recovering the next message (lastMessageId is 384), then 386 will be fetched and the lastMessageId will change to be 386. 385 is then put in the db but never retrieved (stopping and restarting the broker will allow to retrieve the message because at start the lastMessageId is -1). I have synchronized the code inside the RegionBroker.send, and I don't have gaps anymore. This is a workaround for us since we don't process a lot of message. But maybe a more elegant solution is to set the brokerSequenceId in doAddMessage of JDBCAdapter (I may be wrong, I didn't check if the brokerSequenceId is used elsewhere). Is anyone can confirm that this is bug? Thanks -- View this message in context: http://www.nabble.com/Messages-hang-in-Queue-even-when-consumers-are-present-after-failover-tp16422835s2354p16587198.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
