Your case reminds me of ticket AMQ-5266. The ticket says the issue is fixed with 5.11.0, so you should be fine, but perhaps it is a similar issue.
Stephan On Wed, Feb 18, 2015 at 5:08 AM, artnaseef <a...@artnaseef.com> wrote: > Duplicate messages are an unfortunate possibility for any JMS solution, > hence > the JMSRedelivered flag - which comes right out of the JMS specification. > > At some point in a solution such as this, there must be a choice made > between allowing possible duplicates and possible lost messages. JMS chose > possible duplicates. Consider the following sequence of events which I > hope > will make clear why this must be: > > * Broker sends message to consumer > * Consumer receives message and processes > * Consumer sends ack > * Broker terminates before the ack is received or processed > > As far as the consumer is concerned, it is done. But, as you can see, the > broker cannot tell. > > The typical solution is to implement idempotent processing. > > Now, on to the pending message issue - something sounds very wrong here > with > that scenario. If the message stores between the two brokers are indeed > shared, there should be no way for the initially active broker to read > messages off disk that the second broker failed to read - they use the same > logic and code paths and are reading the same files. > > Is it possible that somehow the two brokers don't actually share the same > files? Or, could there be producers around that don't fail-over to the > second broker and therefore look like they have created pending messages on > the first broker that only succeed in being sent after it returns to > service? > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Master-slave-shared-FS-failover-resulting-in-pending-msgs-that-are-not-consumed-until-failed-broker-n-tp4691679p4691692.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
