You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2007/05/24 18:35:16 UTC
[jira] Created: (QPID-499) Provide reaper thread to implement
timeToLive
Provide reaper thread to implement timeToLive
----------------------------------------------
Key: QPID-499
URL: https://issues.apache.org/jira/browse/QPID-499
Project: Qpid
Issue Type: Improvement
Affects Versions: M2
Reporter: Martin Ritchie
Fix For: M3
The timeToLive parameter is available on some of the send methods of the javax.jmx.MessageProducer interface and thus on the qpid implementation (org.apache.qpid.client.BasicMessageProducer) of this interface. However, this flag is not actually implemented i.e. currently just ignored :-(
We need to implement support for this parameter. This requires a check on the AMQP protocol handling of this flag i.e. to check that it can currently be supported. Think it is - but implementer to check and raise if not.
The information below has been extracted from section 4.8 of the JMS specification fyi (see spec for more detail/refs):
A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed). A JMS provider should do its best to expire messages accurately; however, JMS does not define the accuracy provided. It is not acceptable to simply ignore time-to-live.
For more information on message expiration, see Section 3.4.9 "JMSExpiration."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-499) Provide reaper thread to implement
timeToLive
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey resolved QPID-499.
------------------------------
Resolution: Fixed
Resolved on M2 branch
Committed revision 608477.
> Provide reaper thread to implement timeToLive
> ----------------------------------------------
>
> Key: QPID-499
> URL: https://issues.apache.org/jira/browse/QPID-499
> Project: Qpid
> Issue Type: Improvement
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rob Godfrey
> Fix For: M2.1
>
>
> The timeToLive parameter is available on some of the send methods of the javax.jmx.MessageProducer interface and thus on the qpid implementation (org.apache.qpid.client.BasicMessageProducer) of this interface. However, this flag is not actually implemented i.e. currently just ignored :-(
> We need to implement support for this parameter. This requires a check on the AMQP protocol handling of this flag i.e. to check that it can currently be supported. Think it is - but implementer to check and raise if not.
> The information below has been extracted from section 4.8 of the JMS specification fyi (see spec for more detail/refs):
> A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed). A JMS provider should do its best to expire messages accurately; however, JMS does not define the accuracy provided. It is not acceptable to simply ignore time-to-live.
> For more information on message expiration, see Section 3.4.9 "JMSExpiration."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-499) Provide reaper thread to implement
timeToLive
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555569#action_12555569 ]
Rob Godfrey commented on QPID-499:
----------------------------------
Earlier work alowed expired messages on the broker to be removed when they were encountered when searching for the next message to be delivered to a consumer. This provided TTL support when there were consumers attached to a queue.
However, if there is a queue without consumers (e.g. a surable topic subscription where the client is not currently active) then messages which are expired are not "reaped". This may lead to OOM exceptions.
Because of the complicated implementation of queues and the locking thereof; rather than implementing a reaper thread that checks across all queues; it is safer to implement a reaper thread that only looks at queues with no consumers. Where it finds such a queue, it may lock said queue, inspect it for expired messages, and remove such.
> Provide reaper thread to implement timeToLive
> ----------------------------------------------
>
> Key: QPID-499
> URL: https://issues.apache.org/jira/browse/QPID-499
> Project: Qpid
> Issue Type: Improvement
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rob Godfrey
> Fix For: M2.1
>
>
> The timeToLive parameter is available on some of the send methods of the javax.jmx.MessageProducer interface and thus on the qpid implementation (org.apache.qpid.client.BasicMessageProducer) of this interface. However, this flag is not actually implemented i.e. currently just ignored :-(
> We need to implement support for this parameter. This requires a check on the AMQP protocol handling of this flag i.e. to check that it can currently be supported. Think it is - but implementer to check and raise if not.
> The information below has been extracted from section 4.8 of the JMS specification fyi (see spec for more detail/refs):
> A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed). A JMS provider should do its best to expire messages accurately; however, JMS does not define the accuracy provided. It is not acceptable to simply ignore time-to-live.
> For more information on message expiration, see Section 3.4.9 "JMSExpiration."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-499) Provide reaper thread to implement
timeToLive
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey updated QPID-499:
-----------------------------
Fix Version/s: (was: M3)
M2.1
> Provide reaper thread to implement timeToLive
> ----------------------------------------------
>
> Key: QPID-499
> URL: https://issues.apache.org/jira/browse/QPID-499
> Project: Qpid
> Issue Type: Improvement
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rob Godfrey
> Fix For: M2.1
>
>
> The timeToLive parameter is available on some of the send methods of the javax.jmx.MessageProducer interface and thus on the qpid implementation (org.apache.qpid.client.BasicMessageProducer) of this interface. However, this flag is not actually implemented i.e. currently just ignored :-(
> We need to implement support for this parameter. This requires a check on the AMQP protocol handling of this flag i.e. to check that it can currently be supported. Think it is - but implementer to check and raise if not.
> The information below has been extracted from section 4.8 of the JMS specification fyi (see spec for more detail/refs):
> A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed). A JMS provider should do its best to expire messages accurately; however, JMS does not define the accuracy provided. It is not acceptable to simply ignore time-to-live.
> For more information on message expiration, see Section 3.4.9 "JMSExpiration."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-499) Provide reaper thread to implement
timeToLive
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey reassigned QPID-499:
--------------------------------
Assignee: Rob Godfrey
> Provide reaper thread to implement timeToLive
> ----------------------------------------------
>
> Key: QPID-499
> URL: https://issues.apache.org/jira/browse/QPID-499
> Project: Qpid
> Issue Type: Improvement
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rob Godfrey
> Fix For: M3
>
>
> The timeToLive parameter is available on some of the send methods of the javax.jmx.MessageProducer interface and thus on the qpid implementation (org.apache.qpid.client.BasicMessageProducer) of this interface. However, this flag is not actually implemented i.e. currently just ignored :-(
> We need to implement support for this parameter. This requires a check on the AMQP protocol handling of this flag i.e. to check that it can currently be supported. Think it is - but implementer to check and raise if not.
> The information below has been extracted from section 4.8 of the JMS specification fyi (see spec for more detail/refs):
> A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed). A JMS provider should do its best to expire messages accurately; however, JMS does not define the accuracy provided. It is not acceptable to simply ignore time-to-live.
> For more information on message expiration, see Section 3.4.9 "JMSExpiration."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.