5 Replies Latest reply on Oct 16, 2007 4:56 AM by Sanne de

    False negatives and jms

    Sanne de Novice

      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

        • 1. Re: False negatives and jms
          Tim Fox Master

          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.

          • 2. Re: False negatives and jms
            Sanne de Novice

            Hi Tim,

            Exactly! Thanks for your authorative reply.

            Brgrds!

            Sanne

            p.s. no wishlist yet?

            • 3. Re: False negatives and jms
              Elias Ross Master

              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.

              • 4. Re: False negatives and jms
                Tim Fox Master

                 

                "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.


                • 5. Re: False negatives and jms
                  Sanne de Novice

                  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