False negatives and jms

[sanne]

Hi all,

I'm trying to get a clear picture of JMS messaging usage in the context of TCP/IP.

Durable messaging was designed with guaranteed delivery in mind. If a remote client delivers a durable message to theJMS server, then the client be sure the message will reach its destination if there are no exceptions during the posting of the message by the client to the server.

But if I am correct there is always a slight margin for error. This window appears after the message has been committed to the store and before the client returns from communication.

Is it possible that a client receives an error while the message was actually delivered?This would be a false negative. False positives are unaccpetable in the context of queueing, but in avoiding false positives the chance of false negatives remains/increases.

Is this correct?

Best regards,

Sanne

[timfox]

If the call to send a persistent message to a persistent destination returns successfully with no exception, then you can be sure that the message was persisted.

However if the call doesn't return successfully e.g. if an exception is thrown, then you *can't be sure the message wasn't persisted*. Since the failure might have occurred after persisting the message but before writing the response to the caller.

So, yes you are correct. This is a common attribute of any RPC type call: You can't tell by the call not returning that the call didn't actually succeed. Whether it's a web services call, an HTTP get request, an ejb invocation the same applies.

The trick is to code your application so your operations are *idempotent* - i.e. they can be repeated without getting the system into an inconsistent state.

With a message system you can do this on the application level, by checking for duplicate messages, and discarding them if they arrive.

[sanne]

Hi Tim,

Exactly! Thanks for your authorative reply.

Brgrds!

Sanne

p.s. no wishlist yet?

[genman]

I was part of this conversation about a year ago:

http://jira.jboss.org/jira/browse/JBMESSAGING-604

But you can implement a pretty decent solution on the client side by generating your own unique business transaction ID and processing on the consumer side only if that transaction ID was never processed before.

[timfox]

"genman" wrote:

But you can implement a pretty decent solution on the client side by generating your own unique business transaction ID and processing on the consumer side only if that transaction ID was never processed before.

Yes indeed.

Discarding duplicates is a very powerful solution that can often obviate the need for slow XA and still provide once and only once guarantees.

[sanne]

Hi genman,

Yes. Providing business transation id's is an overall design principle.
It can also provice a means of determining cause and effect.

Thanks for that.

Brgrds,

Sanne