[mlange]

Yes, implementing the duplicate detection on the consumer was also proposed by Justin. But it is rather complicated as we have a lot of distributed consumers. Wouldn't it make more sense to implement that on the server side as it is for the producers? The duplicated id cache is there.

I am aware that the usage of own threads is not the recommended way in J2EE. But as you said, sometimes there is no other option. If MDBs were an option we would have used them for sure.

[ataylor]

Yes, implementing the duplicate detection on the consumer was also proposed by Justin. But it is rather complicated as we have a lot of distributed consumers. Wouldn't it make more sense to implement that on the server side as it is for the producers? The duplicated id cache is there.

That wouldn't make sense as the cache needs to be maintained by the resource receiving the possible duplicates, for sends this is the server, for receives this would be the client or clients, if you have distributed clients then this would have to be a distributed cache which makes it slow which negates the gain from using it, so we once again return to using XA.

I am aware that the usage of own threads is not the recommended way in J2EE. But as you said, sometimes there is no other option. If MDBs were an option we would have used them for sure.

Is the reason you are not using MDB's because you need to register/unregister them dynamically, if so in AS7 Im sure the CLI gives you tools to do this, and you can also use the CLI programatically, altho I couldn't tell you how this is done.

[mlange]

That wouldn't make sense as the cache needs to be maintained by the resource receiving the possible duplicates, for sends this is the server, for receives this would be the client or clients, if you have distributed clients then this would have to be a distributed cache which makes it slow which negates the gain from using it, so we once again return to using XA.

Maybe I am thinking too simple: IIRC on the producer side the message is not routed when it is a duplicate. Can't the same check be made later when the message is delivered to the consumer? It could only apply to messages being redelivered as the failover case causes the redelivery.

Is the reason you are not using MDB's because you need to register/unregister them dynamically, if so in AS7 Im sure the CLI gives you tools to do this, and you can also use the CLI programatically, altho I couldn't tell you how this is done.

The problem is that the consumers are provided by developers using  an api which wraps the JMS logic. So the consumers are registered programmatically. No chance to access CLI in that way.

[ataylor]

Maybe I am thinking too simple: IIRC on the producer side the message is not routed when it is a duplicate. Can't the same check be made later when the message is delivered to the consumer? It could only apply to messages being redelivered as the failover case causes the redelivery.

The check has to be done where the message arrives, if you think about it all the server knows is that it has sent a message to the consumer, if it crashes at this point it has no idea whether the message was actually put on the wire, received by the consumer or actually consumed.

The problem is that the consumers are provided by developers using  an api which wraps the JMS logic. So the consumers are registered programmatically. No chance to access CLI in that way.

You could try to do what basically the app server does, on an MDB the app server would typically do this.

get the Transactionmanager

enlist the session with

start a transaction

//the message would then be consumed.

//do some of your logic, if it can be done as part of the tx all the better

end the transaction

prepare the transaction

commit or rollback depending on your logic.

If a crash occurs while the tm is trying to commit then the tm will try to recover later by either rolling back or committing, depending on the state of the tx. If there is a heuristic then the tm will log this to the console.

As long as you can get a handle on the transaction manager you could try the same, although it is quite complex.