Support Timing Messages with Arbitrary Time Delay.(#83)

[echooymxq]

No description provided.

[lizhanhui]

It's true that there is some nuance between delay-delivery-message and scheduled-message when time source is considered. But, IMO, we may offer two API for them using the same underlying implementation. Aka, express the concept of delay-delivery through existing delivery_timestamp field as JMS 2.0 Spec

With JMS 2.0, you can specify a delivery delay when sending a message. The queue manager does not deliver the message until after the specified delivery delay has elapsed.

An application can specify a delivery delay in milliseconds, when it sends a message, by using either MessageProducer.setDeliveryDelay(long deliveryDelay) or JMSProducer.setDeliveryDelay(long deliveryDelay). This value is added to the time at which the message is sent and gives the earliest time at which any other application can get that message.

[echooymxq]

@lizhanhui Sorry for late reply, really respect your wrok. As I understand it, like (JMS(ActiveMQ), the delivery_delay should be send to broker and the broker calculated the actually delivery_time. I don't know if I'm understanding you correctly, you mean like pulsar? pulsar support deliverAt and deliverAfter, the actual delivery time is calculated by the client.

[lizhanhui]

@lizhanhui Sorry for late reply, really respect your wrok. As I understand it, like (JMS(ActiveMQ), the delivery_delay should be send to broker and the broker calculated the actually delivery_time. I don't know if I'm understanding you correctly, you mean like pulsar? pulsar support deliverAt and deliverAfter, the actual delivery time is calculated by the client.

Yes, I am suggesting to calculate delivery-time on the client side for these two API, allowing brokers to process them in a unified manner.

Will the difference be significant enough that we add a new field for it?

[fanlunyong]

这是来自QQ邮箱的自动回复邮件。   您好，请您放心您的邮件我已经收到。我将在看过邮件后，尽快给您回复。