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> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
