[jiwils]

Clebert Suconic wrote:

@Stuart: can you open a JIRA for this? I had one open at some point but I closed it in favor of XA for receiving as I didn't think about this solution by then.

Call it "Making non XA Transactions Idempotent for receiving messages with reconnection or failover"

Stuart White wrote:

@Clebert: I am out of town and will return late next week and will open the JIRA then. Thanks.

I created HORNETQ-694 for this given Stuart's comments.

[timfox]

Clebert Suconic wrote:

Ah, on consume. This is a classic issue, that affects just about every messaging system I know of.

I believe I found a solution that will work for us. Having failover do some sort of duplicate detection using IDs on failover.

I will post it next week on he dev-forums.

We discussed this a lot while I was still at JBoss. Yes, you *could* do something like keep a cache of transactions ids which have successfully committed and check this after failover if a commit is indeterminate. But this is a PITA to implement - you would need to replicate this IDs to the backup so they are available after failover (yuck) and you'd have to change the wire format to support the check.

In other words, quite a lot of work and quite hacky. If it was me I wouldn't bother. No other messaging system that I know of does this anyway. Like I say, the normal thing to do here is dup detection on the client side. Strictly, you'd have to do client side dup detection *anyway* if you want once and only once even without failover, since if a single server crashes the same thing applies about redeliveries.

If I were you I'd spend the time finishing journal replication - which is really important

[leosbitto]

Tim Fox wrote:

the normal thing to do here is dup detection on the client side.

This can get tricky if the clients (consuming from the same queue) run in different JVMs.

Strictly, you'd have to do client side dup detection *anyway* if you want once and only once even without failover, since if a single server crashes the same thing applies about redeliveries.

Another option seems to be to use XA - if the commit fails, you can list the prepared but not commited transactions and see whether your transaction was committed by the server or not.

[clebert.suconic]

I'm thinking about using the duplCache component to store the latest tx Ids on journal, and having the tx to retry and verify if the Id is on the backup.

But that will be for later. We have other priorities as you said.

[clebert.suconic]

BTW: Just a word about this, since some of the competition is putting links to this thread.

It's not like we are losing messages on failover.

A transaction may have been already accepted on failover.

If you used XA to coordinate the commits between two resources, this wouldn't happen.

You can also use duplicate detection to make sure the Transaction was already accepted before.

And as any other software we are always improving things. It is already accptable behaviour and we will improve it even more.