[
https://issues.apache.org/jira/browse/AMQ-8320?focusedWorklogId=906916&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906916
]
ASF GitHub Bot logged work on AMQ-8320:
---------------------------------------
Author: ASF GitHub Bot
Created on: 26/Feb/24 10:28
Start Date: 26/Feb/24 10:28
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #1157:
URL: https://github.com/apache/activemq/pull/1157#issuecomment-1963789165
It also now occurs to me it may not handle foreign providers Message
properly since it seemingly doesnt call setJMSDeliveryTime at all on send
(unless thats being done elsewhere already...though doesnt seem obvious it
could know the value to use).
Although the PR title makes it clear that it does, it also seems weird this
change only covers the JMSProducer API related code, and misses out the
MessageProducer related API, when delivery delay support applies equally to
both (and the underlying send code is used for both).
Issue Time Tracking
-------------------
Worklog Id: (was: 906916)
Time Spent: 1h 20m (was: 1h 10m)
> Implement JMS 2.0 Message.deliveryDelay
> ---------------------------------------
>
> Key: AMQ-8320
> URL: https://issues.apache.org/jira/browse/AMQ-8320
> Project: ActiveMQ Classic
> Issue Type: New Feature
> Reporter: Matt Pavlovich
> Assignee: Matt Pavlovich
> Priority: Major
> Fix For: 6.1.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Relevant sections from the JMS 2.0 specification:
> {noformat}
> 3.4.13.JMSDeliveryTime
> When a message is sent, the JMS provider calculates its delivery time by
> adding the delivery delay value specified on the send method to the time the
> message
> was sent(for transacted sends, this is the time the client sends the message,
> not the time the transaction is committed). It is represented as a long value
> which
> is defined as the difference, measured in milliseconds, between the delivery
> time time and midnight, January 1, 1970 UTC.On return from the send method,
> the
> message’s JMSDeliveryTime header field contains this value. When a message is
> received its JMSDeliveryTime header field contains this same value.A
> message's
> delivery time is the earliest time when a provider may make the message
> visible on the target destination and available for delivery to consumers.
> Clients must
> not receive messages before the delivery time has been reached.
> {noformat}
> {noformat}
> 7.9.Message delivery delay
> A client can specify a delivery delay value in milliseconds for each message
> it sends. This is used to determine the message’s delivery time which is
> calculated
> by adding the delivery delay value specified on the send method to the time
> the message was sent(for transacted sends, this is the time the client sends
> the
> message, not the time the transaction is committed).A message’s delivery time
> is the earliest time when a JMS provider may deliver the message to a
> consumer.
> The provider must not deliver messages before the delivery time has been
> reached.If a message is published to a topic, it will only be added to a
> durable or
> non-durable subscription on that topic if the subscription exists at the time
> the message is sent. An application may specify the required delivery delay
> using
> the method setDeliveryDelay on the producer object. This sets the delivery
> delay of all messages sent using that producer. Note however that the
> setDeliveryDelay method on Message cannot be used to set the delivery delay
> of a message.
> See also section 3.4.13 “JMSDeliveryTime”
> {noformat}
> Approach:
> 1. Use scheduler support to delay deliver of message until the specified time
> 2. Throw an exception from the Broker is the field is non-zero and scheduler
> support is disabled
> 3. MessageProducer sets JMSDeliveryTime header field value
> 4. Note: DeliveryDelay is not honored when set on the Message directly, must
> be set by the MessageProducer (similar to priority, expiry, etc)
> Optional follow-on (probably separate JIRA):
> 1. Consider DestinationPolicy value to override client setting
> 2. Consider DestinationPolicy value to ignore client setting
> JMS v1.1 compatibility support:
> 1. Add ConnectionFactory method .setDeliveryDelayAsProperty(boolean )
> (default: true in 5.17.x)
> 2. Connection sets the delivery delay value as a Property on produce
> 3. Connection removes the property on consume
> 4. Test over network of brokers
> 5. Test scheduler delivery over network of brokers (ensure no
> double-scheduling occurs)
> JMS v2.0 support:
> 1. Update to openwire v13 to add header field for deliveryDelay
> 2. Maintain DeliveryDelayAsProperty support
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
