4 Replies Latest reply on May 16, 2012 11:18 AM by ataylor

    How is time and timezones used in relation to TTL on messages?

    garneke11

      I am currently working on a project that uses a topic as a central repository for separate application to publish status messages. 

      The messages are consumed by one or more display application for users to monitor system activities. 

      The messages are designed to be short lived and are published at a rate of one per second  their TTL is set for 10 seconds. 

       

      I recently came across a scenario where my windows host was running with at timezone of GMT-5 and DST was on. 

      The Solaris server that was hosting my Hornetq Topic was running with a timezone of GMT 0 DST was off.

       

      I could not get any messages that were published from the windows host to appear on any consumer status window. 

      After considerable testing I came to the conclusion that I had to increase my TTL for the status message to be more than 6 hours in order for the messages to appear. 

      Newer versions of Hornetq would actually log that the messages were received as expired unless the TTL exceeded the (timezone + DST+ time drift) differential.

       

      Is the TTL calculated from a timestamp in the message header from the sending host?  I do not know how to make this work in my environment. 

      How can I assume all of the hosts that my customers use have their time in sync ( - rhetorical can't ) .

       

      If I increase my TTL to the extent necessary here I am going to have a crap load of messages building up in my topic and wasting precious drive space.

      I made the assumption that the TTL was based off the time the message was received by the server not send by the client.

       

      How have other people handled this when communicating between separate hosts? 

        • 1. Re: How is time and timezones used in relation to TTL on messages?
          clebert.suconic

          We have had discussions in the past about it. You should have client and server using the same time, and have time-zone set correctly.

           

          We have an open jira to compensate the time from the server, but honesly I'm not sure how that could be done properly. We would be inventing a timing protocol where there are other solutions for that already.

           

           

          We may come up with a solution, but the optimal solution is always to setup client and server to the same GMT time and have the timezones set correctly.

          • 2. Re: How is time and timezones used in relation to TTL on messages?
            garneke11

            I am sure you have thought about this more than me, but what is the down side to only using the server's time? 

            That is to say...  having the TTL begin from the moment the message is recieved by the server not sent from the client.

            Then the clients time would be moot. 

             

            The TTL in its simplest is just its relative time or life span from the moment it is "available" for consumption on the server. 

            • 3. Re: How is time and timezones used in relation to TTL on messages?
              garneke11

              btw - One more comment about the proper setup of client and server time. 

              In my tests, the GMT time for the hosts were correct ( the same ). 

               

              Hornetq did not appear to take the timezone and DST information into account.

               

              Is there something special I have to do in the creation of the message to indicate the timezone?

              • 4. Re: How is time and timezones used in relation to TTL on messages?
                ataylor

                The JMS spec actually states that it should be calculated on the send method. However even if it didnt, Just because a message is sent doesn't mean it is available to a consumer, think of paging or if a message is redistributed around a cluster, it could be some time before the message is available so again this is non deterministic.