Emran,
Thanks for the examples.
On 08/08/2011 13:41, emran wrote:
> Few use-cases where this feature would be useful:
>
> 1) Let us a say bank 'XYZ' wants to send SMS reminders to the customers about the due date for credit-card payment. And
> it wants to send the reminders at certain intervals of time, say reminders on Aug 1, Aug 10, Aug 15 & Aug 19 for a
> due-date on Aug 20. This feature would be very helpful to handle all the use-cases that fall into this category. The
> application can send all the 4 reminder messages at the same time with different delivery times.
OK.
>
> 2) Enterprise Systems use-cases : Let us say JMS is being used as a middleware to connect multiple sub-systems in a big
> Enterprise System. Let us say output from System A is processed by System B at a specific time in future. In these
> cases, the current feature would allow System A to send messages with a delivery time matching the scheduled processing
> start time of System B.
I don't see why we need "delivery delay" to handle this second case. If System B is not running then messages will
simply be saved in the queue or durable topic subscription. When System B starts it will start consuming these messages.
This is how JMS behaves now.
Indeed it seems to me that expecting the producer to know about the availability of the consumer is undesirable and
contrary to the principles of JMS.
(More views welcome)
Nigel
>
> Coming to the API, I had a system property in mind when i proposed. Something like, "JMSXDeliveryTime". Developers who
> need delivery time would set this property. But the API on MessageProducer and Message (as Nigel proposed below) looks
> better than the property approach.
>
> Regards,
> Emran.
>
>
> ----- Original Message ----- From: "Nigel Deakin" <nigel.deakin_at_oracle.com>
> To: <jsr343-experts_at_jms-spec.java.net>
> Sent: Monday, August 08, 2011 4:39 PM
> Subject: [jsr343-experts] (JMS_SPEC-44) New API to specify delivery delay
>
>
>> I have logged this JIRA issue:
>> http://java.net/jira/browse/JMS_SPEC-44
>>
>> This issue was raised by Emran and Tom, though the wording is my own.
>>
>> I've modelled the API proposals below on the existing API for time-to-live/expiration time since I think a consistent
>> API is important in making it easy to understand.
>>
>> Please share your views on (1) the general desirability of such a feature and (2) the actual API proposed.
>>
>> Tom/Emran (and others): it would be helpful if you could give some more information on what this feature (which I know
>> some JMS providers already offer) would be used for.
>>
>> Nigel
>>
>> ------------------------------------------------------------------------------
>> This is a proposal to allow a JMS client to specify a delivery delay when sending a message. If a delivery delay has
>> been specified for a message then the message will not be delivered to any consumers until after the delivery delay
>> has expired.
>>
>> This feature has also been referred to as "delivery time", "timed messages" or "future messages".
>>
>> The API for delivery delay is intended to be similar to that for the existing timeToLive property of a MessageProducer
>> and the corresponding JMSExpiration header field of a Message.
>>
>> There would be new methods on javax.jms.MessageProducer:
>>
>> *** public void setDeliveryDelay(long deliveryDelay) throws javax.jms.JMSException;
>>
>> This sets the minimum length of time in milliseconds from its dispatch time
>> that a produced message should be retained by the messaging system before
>> delivery to a consumer.
>>
>> If the delivery delay is greater then the time to live then the message
>> will always be expired before delivery.
>>
>> *** public long getDeliveryDelay()
>>
>> Returns the minimum length of time in milliseconds from its dispatch time
>> that a produced message should be retained by the messaging system before delivery to a consumer.
>>
>> There would be new methods on javax.jms.Message:
>>
>> *** public long getJMSDeliveryTime() throws JMSException
>>
>> Returns the message's delivery time.
>>
>> When a message is sent, the JMSDeliveryTime header field is left unassigned.
>> After completion of the send or publish method, it holds the minimum delivery time time
>> of the message. This is the sum of the delivery delay value specified by the client and
>> the GMT at the time of the send or publish.
>>
>> When the delivery delay is specified as zero, JMSDeliveryTime is set to zero to indicate
>> that there is no delivery delay.
>>
>> A provider must not deliver a message before the defined delivery time has been reached.
>>
>> *** public void setJMSDeliveryTime(long deliveryTime) throws JMSException
>>
>> Sets the message's delivery time.
>>
>> JMS providers set this field when a message is sent.
>> This method can be used to change the value for a message that has been received.
>>
>> Note that this public method is not intended for use by clients but is needed to allow providers to set this value on
>> a message implemented by a different provider. There is a separate issue to clarify this behaviour:
>> http://java.net/jira/browse/JMS_SPEC-34
>>
>>
>>
>>
>>
>