This discussion is archived
11 Replies Latest reply: Oct 4, 2012 5:54 AM by 959498 RSS

Lost message from server's point of view

959498 Newbie
Currently Being Moderated
Hi All

Following situation:

The JMS-Provider sends a JMS-Message. The message is entirely in the wire and is still flying to the consumer. Before the message arrives to the consumer, the network connection fails, so the client does nothing know about the send message.

From the server’s point of view the message was successfully sent but not acknowledged yet. The server waits for an acknowledge and doesn’t undertake redelivery, because the consumer session on the server is still living.

From the consumer point of view the message was not sent so the client has nothing to ack, so we have some “deadlock”.

The question is – how does server recognize such situation (short connection fail, deadlock) and what does it undertake to guarantee the delivery?

Thank you.
  • 1. Re: Lost message from server's point of view
    nigeldeakin Explorer
    Currently Being Moderated
    The JMS-Provider sends a JMS-Message. The message is entirely in the wire and is still flying to the consumer. Before the message arrives to the consumer, the network connection fails, so the client does nothing know about the send message.

    From the server’s point of view the message was successfully sent but not acknowledged yet. The server waits for an acknowledge and doesn’t undertake redelivery, because the consumer session on the server is still living.

    From the consumer point of view the message was not sent so the client has nothing to ack, so we have some “deadlock”.

    The question is – how does server recognize such situation (short connection fail, deadlock) and what does it undertake to guarantee the delivery?
    If the "network connection fails" whilst sending a message then the server (and probably the client) will almost certainly receive a SocketException. A message is unlikely to simply disappear on the wire without at least one end of the socket getting an exception of some kind, and if the socket is simply hanging for some reason then most JMS providers would have a means to detect this (e.g. by sending periodic packets down the wire to check it is still alive).

    But ultimately, if a persistent message is sent to a consuming client and the message is not acknowledged (or the transaction committed) then the server will eventually redeliver it. JMS doesn't define exactly when an unacknowledged message is redelivered, but it typically wouldn't happen until the consumer in question has closed.

    Nigel
  • 2. Re: Lost message from server's point of view
    jtahlborn Expert
    Currently Being Moderated
    Also, most JMS providers will have reliable ways to store persistent messages (such as a database), so a persistent message would never exist solely on the network. so, when the JMS impl detects an interruption in the communication infrastructure (socket exception) it can resend the message from the persistent storage.
  • 3. Re: Lost message from server's point of view
    959498 Newbie
    Currently Being Moderated
    During the send method is blocked, some error (e.g. network connection fails) can happen when:

    - The message is flying to the server
    - The ack is flying to the client

    In both cases the client session throws a JMSException so the sender knows about some error. ok.

    The question is, how can I (client) distinguish these two cases? Sending same message again could result in a double message…

    Is it possible using some jms features to say to the server “this message has been already sent. If you have it, just ignore it, otherwise take it”. All what I know, is the JMSRedelivery-Flag, but, accordingly to the jms specification, this flag is set only by jms-provider.

    Thank you

    Edited by: 956495 on 02.10.2012 09:56
  • 4. Re: Lost message from server's point of view
    jtahlborn Expert
    Currently Being Moderated
    956495 wrote:
    During the send method is blocked, some error (e.g. network connection fails) can happen when:

    - The message is flying to the server
    - The ack is flying to the client

    In both cases the client session throws a JMSException so the sender knows about some error. ok.
    no, the jms implementation should be handling these network interruptions for you. you should only be receiving an exception if the send operation failed (at least for a decent jms implementation).
  • 5. Re: Lost message from server's point of view
    nigeldeakin Explorer
    Currently Being Moderated
    956495 wrote:
    During the send method is blocked, some error (e.g. network connection fails) can happen when:

    - The message is flying to the server
    - The ack is flying to the client

    In both cases the client session throws a JMSException so the sender knows about some error. ok.

    The question is, how can I (client) distinguish these two cases? Sending same message again could result in a double message…
    If the call to send() throws an exception (and you're not using a transaction) then you can't be sure whether the message was successfully added to the queue or topic.

    If you're sending the message in an XA transaction (i.e. you're using a Java EE application) and you get an exception whilst trying to commit you should be able to use the transaction manager to retry the commit without a risk of duplicates.

    Nigel
  • 6. Re: Lost message from server's point of view
    959498 Newbie
    Currently Being Moderated
    If the call to send() throws an exception (and you're not using a transaction) then you can't be sure whether the message was successfully added to the queue or topic.

    It means, a non-transactional jms session doesn't provide 100% guaranty of delivering message. Right?

    If you're sending the message in an XA transaction (i.e. you're using a Java EE application)  and you get an exception whilst trying to commit you should be able to use the transaction manager to retry the commit without a risk of duplicates.

    I dont use an xa-transaction. I'm just experementing with a standalone jms client.

    What about a jms transactional session (connection.createSession(true,-1)), does it solve the problem of undelivered / duplicate message?
  • 7. Re: Lost message from server's point of view
    800381 Explorer
    Currently Being Moderated
    Any messaging system that guarantees delivery will always have the possibility of delivering a message more than once.

    If your code can't handle that, your code is broken and needs to be fixed.
  • 8. Re: Lost message from server's point of view
    EJP Guru
    Currently Being Moderated
    Any messaging system that guarantees delivery will always have the possibility of delivering a message more than once.
    This is completely untrue. Any system that uses sequence numbers, or any other measure to make transmissions idempotent, can easily avoid redelivery.
  • 9. Re: Lost message from server's point of view
    jtahlborn Expert
    Currently Being Moderated
    user5287726 wrote:
    Any messaging system that guarantees delivery will always have the possibility of delivering a message more than once.

    If your code can't handle that, your code is broken and needs to be fixed.
    if you read back through the thread, you will see that the question is not about message delivery, it is about message sending.
  • 10. Re: Lost message from server's point of view
    jtahlborn Expert
    Currently Being Moderated
    956495 wrote:
    If the call to send() throws an exception (and you're not using a transaction) then you can't be sure whether the message was successfully added to the queue or topic.

    It means, a non-transactional jms session doesn't provide 100% guaranty of delivering message. Right?
    you are conflating sending and delivering, which are two different things. as @nigeldeakin pointed out, if you are not using transactions, and the send method throws an exception, the client does not know if the messages was successfully sent or not (this is addressed in section 4.4.13 of the JMS spec, version 1.1). if the message was successfully sent, and you are using persistent messaging, then the message will be delivered to the consumer.
    If you're sending the message in an XA transaction (i.e. you're using a Java EE application)  and you get an exception whilst trying to commit you should be able to use the transaction manager to retry the commit without a risk of duplicates.

    I dont use an xa-transaction. I'm just experementing with a standalone jms client.

    What about a jms transactional session (connection.createSession(true,-1)), does it solve the problem of undelivered / duplicate message?
    yes, if you use transactions, you can use that facility to handle reliably sending the message without duplicating. (again, this has nothing to do with eventual delivery of the message to the consumer).
  • 11. Re: Lost message from server's point of view
    959498 Newbie
    Currently Being Moderated
    Thanks for your explanation.

    yes, if you use transactions, you can use that facility to handle reliably sending the message without duplicating.

    Hm, but the specification says, a transaction can NOT guarantee non-duplicatig message:

    If a failure occurs between the time a client commits its work on a Session and the commit method returns, the client cannot determine if the transaction was committed or rolled back.

    Doesn't it contradict to that you said?

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points