[
https://issues.apache.org/jira/browse/AMQ-8320?focusedWorklogId=906915&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-906915
]
ASF GitHub Bot logged work on AMQ-8320:
---------------------------------------
Author: ASF GitHub Bot
Created on: 26/Feb/24 10:27
Start Date: 26/Feb/24 10:27
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #1157:
URL: https://github.com/apache/activemq/pull/1157#issuecomment-1963786335
Seems like the same code as the old PR, so [same comment from
before](https://github.com/apache/activemq/pull/982#issuecomment-1438292774):
<blockquote>
Since message objects can be reused/resent, and might already have an
existing value for JMSDeliveryTime, it should always be setting the
JMSDeliveryTime value on send even if there isnt a delay, to ensure the
JMSDeliveryTime value on the message after send reflects behaviour of that send
and not some previous send or receive.
That doesnt mean it has to transit a delivery time on the wire...ideally it
wouldnt if there is no delay being requested for this send...just that after
send the local message object should report the delivery time for that send.
Elsewhere I added an internal message method to set the value and note whether
it is for transmission.
It doesnt feel like it should be setting a message property at all, only a
header. I don't expect the TCK tests which check additional properties arent
being added to the messages are using delivery-delay at the time..but they
could. I know the older 'message property extension' scheduling stuff uses one,
but its not clear to me this needs to. They could just be treated as separate
mechanisms, which they kind of are already as you have to choose to respect the
new value on the producer or the old one on the message. Theres no reason the
broker couldnt do the same, and this new mechanism essentially ignore that old
prop.
</blockquote>
Issue Time Tracking
-------------------
Worklog Id: (was: 906915)
Time Spent: 1h 10m (was: 1h)
> 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 10m
> 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)
