5 Replies Latest reply on Jan 13, 2006 1:46 AM by Scott Stark

    JMS remote subscriber clock synchronization

    Marc Cobery Newbie


      I am connecting to JBossMQ via a remote client. The client can be Windows or Linux based. I am running into problems with retrieving messages due to the client clock and the JBoss Server clock not being synchronized. I have several questions.

      This issue would seem like a common problem, are there any known solutions or work arounds?

      When and where in the JBoss code is the client clock information passed to the JBoss Server?

      Is there a way to sychronize the clocks?

      Since the client application may not always have the user priviledge to sychronize the client clock with the server clock, is there any way to "spoof" the client clock with the server clock?

      Thanks in advance for any help.

      Marc Cobery

        • 2. Re: JMS remote subscriber clock synchronization
          Marc Cobery Newbie

          I need a time to live due to the volume of messages, but this is not the only problem. If the client clock is ever faster than the server I will not receive the message since it will appear to the server that my connection is only wants messages from that time forward.

          From this link, http://docs.sun.com/source/819-0066/strtbrkr.html

          Before starting any brokers or clients, it is important to synchronize the clocks on all hosts that will interact with the Message Queue system. Synchronization is particularly crucial if you are using message expiration (TimeToLive). Timestamps from clocks that are not synchronized could prevent the TimeToLive feature from working as expected and prevent the delivery of messages. Synchronization is also crucial for broker clusters.

          For example, server clock is 11:00 AM and the client is 11:05 AM. The client makes the connection. The JMS server sends a message with a timestamp of 11:00. I will not receive that message since my connection is only interested in messages post 11:05 AM timestamp. Is this a correct assumption? It appears to be how the messaging is implemented. Will an infinite ttl allow for these messages to be retrieved?

          • 3. Re: JMS remote subscriber clock synchronization
            Scott Stark Master

            Yes, clock synchronization is required for the ttl to be valid. At the cost of added overhead the server could act as the central time keeper, but we don't support this.

            Setting the ttl to infinite will remove the clock issue.

            • 4. Re: JMS remote subscriber clock synchronization
              Marc Cobery Newbie

              By setting the ttl to 0, does that mean the topic subscriber will receive all messages that are published to the topic even those messages published before topicsubscriber is created if they have never been acknowledged?

              Would this work:
              -set ttl to 0
              -on application init (when I create the topic subscriber)get server time, drain topic (i.e.acknowledge all messages before that time to get rid of the messages in the messagecache)
              -create topic subscriber that will get the messages from that time forward

              The only problem that might happen here is a build up of messages if no consumers are attached.

              • 5. Re: JMS remote subscriber clock synchronization
                Scott Stark Master

                If there is no subscriber there is no buildup of messages.