5 Replies Latest reply on Feb 23, 2011 2:53 AM by ataylor

    Hornetq reliable message recovery

    rahul_516

      Hi ,

       

      Iam using JMS along with hornetq . Iam making sure that DeliveryMode.PERSISTANT is on for the messages. all the subscriptions are Durable subscription.  The acknowledge mode is CLIENT_ACKNOWLEDGE mode. My acknowledgement is typically sent after 24 hours of accepting the messages. Iam completly dependent on the reliability and failover of the hornetq , as the system which analyses these messages doesnt have failover , all the data is in the memory in this system.

       

      I have following questions:

       

      1. In case of DeliveryMode, DurableSubscription and CLIENT_ACKNOWLEDGE. Suppose If the client crashes or goes down and though Client has RECIEVED the message and Client has NOT acknowledged the message.  Once client comes back , will it again get back all the messages back for which it hasn't send the acknowledgement ?  As in is it automated or do i need to manually recover it ?  In case of Manual do we need to use Session's recover method?

       

      2. Expiry . If a client doesn't sends the acknowledgement for a given message and  Message is expired , Does this mean that Hornetq would send it again or Hornetq would delete is for ever?

       

      3. In case of session recovery . Once JMS client comes up it will directly try to communicate with the the Hornetq server , once the JMS client is up , will it still have the old session . Is Dead connection the one which handles this case?

       

      -rahul

        • 1. Hornetq reliable message recovery
          ataylor
          Iam using JMS along with hornetq . Iam making sure that DeliveryMode.PERSISTANT is on for the messages. all the subscriptions are Durable subscription.  The acknowledge mode is CLIENT_ACKNOWLEDGE mode. My acknowledgement is typically sent after 24 hours of accepting the messages. Iam completly dependent on the reliability and failover of the hornetq , as the system which analyses these messages doesnt have failover , all the data is in the memory in this system.

          Just a note on the fact that you aren't acking your message for an hour, remember that the message won't be deleted from memory until it is acked so if you have a hi throughput you could run into memory/starvation problems, however i'm assuming that this is not the case in your app.

           

          1. In case of DeliveryMode, DurableSubscription and CLIENT_ACKNOWLEDGE. Suppose If the client crashes or goes down and though Client has RECIEVED the message and Client has NOT acknowledged the message.  Once client comes back , will it again get back all the messages back for which it hasn't send the acknowledgement ?  As in is it automated or do i need to manually recover it ?  In case of Manual do we need to use Session's recover method?

           

          At the point that the server detects the client failure (more on this ina bit) any unacked messages are placed back onto the queue and made available for other consumers, so yes, if the client comes back, and the messages weren't consumed by other consumers, it will receive the messages again. This is fully automated and you need to do nothing. All recover does is replay and unacked messages to the sessions consumers.

           

          2. Expiry . If a client doesn't sends the acknowledgement for a given message and  Message is expired , Does this mean that Hornetq would send it again or Hornetq would delete is for ever?

          Yes if a message expires between delivery and redelivery then HornetQ will handle it as expired, either deleting it or forwarding it to the expirey address if one is configured.

          3. In case of session recovery . Once JMS client comes up it will directly try to communicate with the the Hornetq server , once the JMS client is up , will it still have the old session . Is Dead connection the one which handles this case?

          It depends what you mean by comes up? If you mean that the client process has been killed then obviously on restart it will make new connections etc to the server and be treated as such.

           

          let me explain how it works on the server. If the server detects a client failure due to the OS closing the socket then the session state will be removed. If the server doesn't detect the client failure, say if there is some network connectivity problems, then the server will hold on to the state for a configurable set time. This allows clients to reconnect and carry on from where they left off.

          • 2. Hornetq reliable message recovery
            rahul_516

            Thank you for your input Andy , they were really helpful.

             

            For you comment below in bold

             

            At the point that the server detects the client failure (more on this ina bit) any unacked messages are placed back onto the queue and made available for other consumers, so yes, if the client comes back, and the messages weren't consumed by other consumers, it will receive the messages again. This is fully automated and you need to do nothing. All recover does is replay and unacked messages to the sessions consumers.

             

            I had questoin about this.

             

            Incase there are multiple consumers assuming other consumers consumed the messages , but then my consumer came back , will it get all the messages directly or does it need to do session recover to get back the data ?

            • 3. Hornetq reliable message recovery
              ataylor

              If other consumers consume the messages then the consumer coming back up won't receive them, this is correct, with P2P only 1 consumer should ever receive the message.

               

              forget about the recover method, this is used to replay unacked messages not recover rolled back messages.

              • 4. Hornetq reliable message recovery
                rahul_516

                Thank you for your reply Andy.

                 

                Can we depend on the expiry of the messages to make sure that messages are deleted . What will happen if i set the MessageProducer setTimeToLive to say 5 hours and never send the acknowledgement ? I understand the repurcussions on the client side cache , ill make it very small ,because we anyhow store lots of messages in the memory for considerable time.

                From your earlier reply i can see that messages will be deleted if they are expired between delivery and redelivery. But want to know if we can depend on this behaviour ?

                 

                We need pub sub model , but we are storing messages in memory for 24 hours as we do pattern based analytics on those. But this system is memory based and has no failover if goes down. I am depending on the durable subscription model of the hornetq for this. My idea is if my in memory system goes down in between as i have not acknowledged any messages ill get it back incase of crash. But once my 24 hours are over my in memory systems needs fresh set of messages , so new messages will come in and at the same time as i have set the expiry time for messages to be 24 hours , old messages will be discarded. I just have one consumer for these messages.

                 

                Is it a good pattern to use messageQ in the above manner ?

                • 5. Hornetq reliable message recovery
                  ataylor
                  Can we depend on the expiry of the messages to make sure that messages are deleted

                  Expiry can happen either at the server or at the client and uses the System clock so its as dependable as the OS clock.

                   

                  What will happen if i set the MessageProducer setTimeToLive to say 5 hours and never send the acknowledgement ?

                  Not sure what you mean here, acknowledgements have nothing to do with a producer, its consumers that ack.

                   

                  We need pub sub model , but we are storing messages in memory for 24 hours as we do pattern based analytics on those. But this system is memory based and has no failover if goes down. I am depending on the durable subscription model of the hornetq for this. My idea is if my in memory system goes down in between as i have not acknowledged any messages ill get it back incase of crash. But once my 24 hours are over my in memory systems needs fresh set of messages , so new messages will come in and at the same time as i have set the expiry time for messages to be 24 hours , old messages will be discarded. I just have one consumer for these messages.

                  As long as your throughput id low it should be fine, however i can't comment as i don't know your use case. Personally i would probably have used a database where clients put the data and a scheduler to poll every 24 hours to get the new data to work on.