[timfox]

You're missing the point.

The user should retry the commit, when it succeeds we know the ack will has been committed.

This is nothing to do with duplicate detection. Like I've said (3 times now ) acks don't need dup detection since they're idempotent.

[clebert.suconic]

If a user wants to process proper ACKs with failover, he will have to do something like:

ClientMessage msg = consumer.receive(TIMEOUT);

while (retry)

{

     msg.acknowledge();

     session.commit();

}

processMessage(msg); // this is user's code

Which I'm not sure this is necessarily transparent.

If the user is doing something like batching transactions:

ArrayList<ClientMessage> msgs = new ArrayList();

for (int i = 0 ; i < USERS_BATCH_SIZE; i++)

{

      msgs.add(consumer.receive(TIMEOUT);

}

And then call ack on each message, and retry this way.

Which I also think it's a little weird.

Especially that if failover happened at message 20, the buffer will be cleared, and messages[0-10] will be redelivered. So the user will receive duplicates on that case. So, the retry won't really work here.

All I"m saying is: We should deal with those cases and make a commit transparent to the user. Or it is committed or it is not. Put that as a feature request on 2.5 if you like.

[timfox]

I don't really understand the point you're making here.

It's only necessary for the user to retry the commit call, they don't have to reacknowledge the messages too.

[clebert.suconic]

What I would change:

IMO: TransactionRolledBack exception should only mean one thing: It was rolled back! Both for ACKs and Message send.

Currently it's not possible to do any retries on the backup as the ACKs are available only on the live node.

Also currently it's only possible to avoid duplicates during failover if you used Duplicate detection.

To do what I'm proposing, we would need some sort of ID on the client transaction, and if a failure happened during commit or prepare, the failover code could verify if that ID was received on backup or not. If the transaction ID is not on the backup journal.. then it's a rollbackONly.. else.. we accept the commit.

If we do something like that, we wouldn't necessarily need duplicate detection on send. And we wouldn't lose message during consume.

On this case a RolledBackException would have a simple meaning: Rollback your data and try again!

(Of course we would only do this for Persistent Messages).

[timfox]

Actually, you make a good point, now I've finally understood it

I'm going to think about this some more...