Unsynched clocks on JMS Client and Server cause problems with Time To Live
Hello,
I just spent two days diagnosing a tricky problem involving JMS messages and time-to-live. A producer on one PC was sending messages to a Topic on a JMS server, but the JMS server was not sending the messages out to the consumers.
After much trial and error, I determined that the clocks on the producer PC and the JMS server must be in sync or else things go wonky. If the Producer PC is 30 seconds behind the JMS Server and the ttl is set to 30 seconds or less, then all messages from the Producer will immediately time out upon reaching the server since the server thinks they came from 30 seconds ago.
This behaviour seems undocumented, as far as I can tell. It is also counterintuitive. I assumed Time To Live was meant to prevent messages from being sent out if they sat in a queue on the JMS server for too long. Why should the clients' PC clock have any bearing on the "age" of a JMS message?
It is not feasable for us to synch all our producer systems together, but we'd like to use TTL to prevent consumers from getting old messages if they become overloaded. Is there any way we can do this?
Thanks for your help.
[1177 byte] By [
jyzude] at [2007-11-25 17:33:13]
# 1
Yes, we're aware that the clock synchronization interaction with TTL causes
confusion. There is a bug filed on this (4853434), and we will consider
addressing it in an upcoming release. At a minimum we can log a
warning when clock skew is detected, but in the long term we should be
able to compensate and expire messages in a more predictable fashion.
Currently the producing client computes JMSExpiration since its value
must be available to the producer (if it queries the JMSExpiration property
after send). The requirement for clock synchronization is mentioned in the
Administration Guide or Release Notes (depending on the release). We should
make it more visible.
If you're using 3.5 there is a feature that may be appropriate for you
to use (possibly in addition to message expiration). You can specify the
size of a destination, and what action the destination should take if it
fills up. One of those actions is to discard the oldest message. So messages
stay on a queue until they are consumed or the queue fills up at which point
old ones are discarded to make way for new.
See the "Managing Destinations" section of the 3.5 Administration Guide:
http://docs.sun.com/source/817-6024/brkrmgmt.html#wp36113
Hope this helps and sorry that you wasted so much time on this issue.
Joe
http://wwws.sun.com/software/products/message_queue/index.html
jfdp at 2007-7-3 13:36:21 >
