12 Replies Latest reply: Mar 9, 2012 6:27 AM by nigeldeakin RSS

    Re queue any message once it receive

    linkin
      Hi,
      Is it possible to re-queue any message once its receive by consumer.I read one article where it mention that if there is any kind of jms exception occur in that case it is possible. But my question is that is it possible if I use Queue and can I throw it force fully?

      Thanks & Regards
        • 1. Re: Re queue any message once it receive
          DrClap
          There is no rule against a message consumer writing a message to a queue at any time. And exceptions have nothing to do with that lack of a rule.
          • 2. Re: Re queue any message once it receive
            linkin
            Thanks . But If there are certain situation occurred where consumer receive say 5 message from queue and certainly its crash before processing any message. In that case what will happen .

            Thanks & Regards
            • 3. Re: Re queue any message once it receive
              EJP
              Nothing will happen after a crash of course. What did you expect?
              • 4. Re: Re queue any message once it receive
                linkin
                That means the received messages were lost and there is no way to revert back the received message to the queue.One more thing if I use any transaction in that case is it possible to handle the above situation.

                Thanks & Regards
                • 5. Re: Re queue any message once it receive
                  r035198x
                  When an exception occurs the transaction is rolled back and the message is put back onto the source queue. If you suppress (catch) the exception then you can post the message to another queue successfully and the message receipt is not rolled back. If you post it back to the same source queue then you have just done what would have happened if you had not caught the exception. In that case it is possible (perhaps likely) that the message will cause an exception again and be rolled back to the queue again repeating the process forever.
                  Some providers can be configured to automatically count the number of times a message has been redelivered through the JMSXDeliveryCount property and post the message to some error queue if the count exceeds a configured value. The proposed JMS 2 spec now mandates all providers to set this property. For now you need to check the docs of your provider to find out how to configure the auto routing on a max redelivery count if that's what you want.
                  • 6. Re: Re queue any message once it receive
                    EJP
                    It appears so, see Using JMS API Local Transactions in the JMS Tutorial.

                    I suggest you read the whole thing.
                    • 7. Re: Re queue any message once it receive
                      r035198x
                      linkin wrote:
                      That means the received messages were lost and there is no way to revert back the received message to the queue.One more thing if I use any transaction in that case is it possible to handle the above situation.

                      Thanks & Regards
                      If you don't want messages to be lost when a server crashes then set the DeliveryMode as PERSISTENT (this will come at some overhead).
                      • 8. Re: Re queue any message once it receive
                        gimbal2
                        r035198x wrote:
                        linkin wrote:
                        That means the received messages were lost and there is no way to revert back the received message to the queue.One more thing if I use any transaction in that case is it possible to handle the above situation.

                        Thanks & Regards
                        If you don't want messages to be lost when a server crashes then set the DeliveryMode as PERSISTENT (this will come at some overhead).
                        Let me reason about this from a different angle. Yes you can make messages persistent; any message that was on the queue when the system goes down will be saved. But any message sent while the system is down is lost. Even if you make messages persistent, there are still messages getting lost.

                        I'm not making any further claims here, just something that came to mind when I read your reply :)
                        • 9. Re: Re queue any message once it receive
                          r035198x
                          gimbal2 wrote:
                          r035198x wrote:
                          linkin wrote:
                          That means the received messages were lost and there is no way to revert back the received message to the queue.One more thing if I use any transaction in that case is it possible to handle the above situation.

                          Thanks & Regards
                          If you don't want messages to be lost when a server crashes then set the DeliveryMode as PERSISTENT (this will come at some overhead).
                          Let me reason about this from a different angle. Yes you can make messages persistent; any message that was on the queue when the system goes down will be saved. But any message sent while the system is down is lost. Even if you make messages persistent, there are still messages getting lost.

                          I'm not making any further claims here, just something that came to mind when I read your reply :)
                          If "the system is down" means the consumer then those messages will be available when the consumer starts up but messages can get lost when PERSISTENT mode is set because, from the specs


                          Delivery mode covers only the transport of the message to its destination. Retention of a message at the destination until its receipt is acknowledged is not guaranteed by a PERSISTENT delivery mode. Clients should assume that message retention policies are set administratively. Message retention policy governs the reliability of message delivery from destination to message consumer. For example, if a client's message storage space is exhausted, some messages may be dropped in accordance with a site-specific message retention policy.
                          • 10. Re: Re queue any message once it receive
                            nigeldeakin
                            r035198x wrote:
                            Delivery mode covers only the transport of the message to its destination. Retention of a message at the destination until its receipt is acknowledged is not guaranteed by a PERSISTENT delivery mode. Clients should assume that message retention policies are set administratively. Message retention policy governs the reliability of message delivery from destination to message consumer. For example, if a client's message storage space is exhausted, some messages may be dropped in accordance with a site-specific message retention policy.
                            This sounds like a feature specific to a particular JMS provider. Which one, out of interest?

                            JMS requires that if a persistent message is delivered to a consumer in a non-transacted session using CLIENT_ACKNOWLEDGE mode, and the consumer closes the session and connection (or crashes) before it calls message.Acknowledge(), then the message must be redelivered, not thrown away. The client's storage space is irrelevant since the message should continue to be persisted in the server until it is acknowledged.

                            The same applies for messages consumed in a transaction. If a persistent message is delivered to a consumer in a transacted session, and the consumer closes the session and connection (or crashes) before it calls session.commit(), then the message must be redelivered, not thrown away. The client's storage space is irrelevant since the message should continue to be persisted in the server until it is acknowledged.

                            Nigel

                            Edited by: nigeldeakin on 09-Mar-2012 02:48
                            • 11. Re: Re queue any message once it receive
                              r035198x
                              nigeldeakin wrote:
                              r035198x wrote:
                              Delivery mode covers only the transport of the message to its destination. Retention of a message at the destination until its receipt is acknowledged is not guaranteed by a PERSISTENT delivery mode. Clients should assume that message retention policies are set administratively. Message retention policy governs the reliability of message delivery from destination to message consumer. For example, if a client's message storage space is exhausted, some messages may be dropped in accordance with a site-specific message retention policy.
                              This sounds like a feature specific to a particular JMS provider. Which one, out of interest?
                              It's a comment in the specs of the DeliveryMode interface http://docs.oracle.com/javaee/5/api/javax/jms/DeliveryMode.html .It doesn't cite if anyone implemented it that way.
                              • 12. Re: Re queue any message once it receive
                                nigeldeakin
                                r035198x wrote:
                                nigeldeakin wrote:
                                r035198x wrote:
                                Delivery mode covers only the transport of the message to its destination. Retention of a message at the destination until its receipt is acknowledged is not guaranteed by a PERSISTENT delivery mode. Clients should assume that message retention policies are set administratively. Message retention policy governs the reliability of message delivery from destination to message consumer. For example, if a client's message storage space is exhausted, some messages may be dropped in accordance with a site-specific message retention policy.
                                This sounds like a feature specific to a particular JMS provider. Which one, out of interest?
                                It's a comment in the specs of the DeliveryMode interface http://docs.oracle.com/javaee/5/api/javax/jms/DeliveryMode.html .It doesn't cite if anyone implemented it that way.
                                Thanks! That does appear to go beyond what it says in the spec itself (section 4.10) and I think it needs to be clarified in JMS 2.0. I've logged this here:
                                http://java.net/jira/browse/JMS_SPEC-84

                                Nigel