Emran,
On 08/08/2011 03:43 PM, Nigel Deakin wrote:
> ...
> 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.
But what happens, when the customer terminates the account? Or even
dares to pay on Aug 2nd? Will he still receive those other reminders?
Messages would have to be either redrawn or ignored. I don't like to
ignore anything... feels filthy, somehow. Do you keep a list of deleted
accounts? How long? Or do you ignore all messages for accounts that
don't exist? What happens, when you have a bug somewhere that produces
messages with wrong ids? You should be able to notice!
But an API for redrawing messages already sent is not trivial, either.
Esp. because you'd have to store the message-ids for a customer. When
can you delete them? If not all of the messages have to be redrawn,
you'd have to browse them and remove all affected. More and more things
will creep up on you, and you'd be better off to handle all of the
delaying yourself in the first place.
>> 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)
I absolutely agree with Nigel!
We have a lot of long running processes with lots of delays. And the
most important learning we had was that this is never a technical issue
but a business issue. Hiding it in the technology causes a lot of pain.
The business code must stay in control, instead!
Rüdiger
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>
>
>