activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiv Jivan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1160) provide a way of setting the timeToLive from the point in time the message is received by the broker to avoid clock sync issues
Date Fri, 09 Feb 2007 11:26:03 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38490
] 

Sanjiv Jivan commented on AMQ-1160:
-----------------------------------

The spec says a TTL of 0 equals never expire message but I suspect some users might be using
-1 as well and presently see the same behavior of message not expiring. I think using a new
header is a safer option.

The spec also says :
"When a message is sent, its expiration time is calculated as the sum of the timeto-live value
specified on the send method and the current GMT value. On return from the send method, the
message's JMSExpiration header field contains this value."

Its possible that existing client code might be expecting a JMSExpiration value on the message
on send, so I think the JMSExpiration value should be set on the message the way it is done
presently but the ActiveMQ impl can have an API to override this expiration calculation behaviour
to be based on broker time by internally setting a new header which the broker can then check
for prior to checking the JMSExpiration header value.

> provide a way of setting the timeToLive from the point in time the message is received
by the broker to avoid clock sync issues
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-1160
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1160
>             Project: ActiveMQ
>          Issue Type: Improvement
>            Reporter: james strachan
>             Fix For: 4.3.0
>
>
> The JMS default is to use timeToLive relative to the client send; which means things
get converted to GMT and can suffer from clock sync issues.
> A useful alternative could be to set the timeToLive on a message relative to the broker's
clock when it receives it. That way there's no need to rely on a properly sync'd clock.
> So we could either 
> * use a new header - ActiveMQBrokerTimeToLive or something.
> * use a negative time to live value to indicate, its the time to live relative to the
broker (rather than relative to the client)
> Am wondering if the negative timeToLive value would break any existing software? (Currently
we tend to ignore any TTL values less than or equal to zero)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message