I think I've found the code that results in this behavior. DurableTopicSubscription.unmatched() is called when a message fails to match a selector for a given consumer, and it calls Destination.acknowledge() which eventually calls DefaultJDBCAdapter.doSetLastAck(). My suspicion is that this method is being called even if there are pending messages that have not yet been dispatched to the consumer because it's offline.
Would you be able to attach a debugger to your broker (in a non-operational environment, of course) and set a breakpoint on those methods and confirm that that is indeed the code path by which the database is getting updated in your single-consumer scenario that you tested in your most recent response? Thanks, Tim On Wed, Nov 8, 2017 at 11:23 PM, jasons <jason.sm...@au.abb.com> wrote: > Tim, we appreciate any and all help the community can offer and we'll do > what > we can to help ourselves. > > You are correct in that a repeat of the test with only DC1 results in the > same behaviour and outcome. Pending messages for DC1 are lost/deleted > after > messages arrive on the same topic but which don't match DC1's selector; the > LAST_ACKED_ID of DC1 ultimately advances to match that of the highest/last > msg id arriving at the topic. The final message loss occurs only after the > cleanup thread for msg ids at that priority runs. > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
