SourceForge.net
2005-07-22 14:48:52 UTC
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
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