[ openjms-Bugs-1217952 ] Clock drift between client and server affects msg expiration
"SourceForge.net" <[email protected]> Fri, 22 Jul 2005 07:48:52 -0700
| Newsgroups | gmane.comp.java.openjms.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #1217952, was opened at 2005-06-10 00:21 Message generated for change (Comment added) made by rabiedenharn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1217952&group_id=54559 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: client Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Anderson (tanderson) Assigned to: Jim Alateras (jalateras) Summary: Clock drift between client and server affects msg expiration Initial Comment: If there is a significant system clock mismatch between client and server hosts, messages sent with a time-to-live set will expire at times different to that indicated by their JMSExpiration property. The expiration time is an absolute time expressed in milliseconds (i.e the JMSExpiration message property), and is determined in the client. However, the server is responsble for expiring messages. If the server host's clock is advanced relative to the client's, then messages will expire sooner than expected. If the server host's clock is retarded relative to the client's, then messages will expire later than expected. ---------------------------------------------------------------------- Comment By: Rob Biedenharn (rabiedenharn) Date: 2005-07-22 10:48 Message: Logged In: YES user_id=911223 If the time-to-live is being set to less than the discrepancy between system clocks, then the "right" fix should be to sync the clocks! Whether it is client syncing to server or both syncing to a reliable source, the problem becomes moot. Any application that uses message expiration should accept that any message may not make it to the consumer before it expires. If the expiration interval is extremely short, perhaps a message-based communication isn't really the right choice for the application. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1217952&group_id=54559 ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click