[jira] Commented: (AMQ-1517) Support for more graceful handling of timeouts within MessageProducer.send

["Mike Kelley (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/AMQ-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41754#action_41754 ] 

Mike Kelley commented on AMQ-1517:
----------------------------------

Another way to think about it is:
1. How to specify maximum queue size/disk space/etc (done)
2. How to specify send timeout (TBD?)
3. Given (2), what happens when the timeout is reached? (TBD)

I think the {spec|http://dlc.sun.com/pdf/816-5904-10/816-5904-10.pdf} is open to an interpretation that suggests that (2) is already there via the timeToLive argument to MessageProducer.send methods. FWIW Weblogic seems to have chosen an {interpretation|http://edocs.bea.com/wls/docs90/jms_admin/tuning.html#1143603} where it's defined as a (configurable) property of a JMSConnection inherited by MessageProducers.

The spec says the value of the JMSExpiration property should be set to GMT + timeToLive after returning from send, but doesn't seem to say anything about what happens (on the send side) if the timeout reached.  One interpretation would be to set it to a special value (0 or -1?), the other would be to throw an exception. Weblogic throws a ResourceAllocationException. This seems preferable, particularly if the send timeout is specified separately from message time to live.

> Support for more graceful handling of timeouts within MessageProducer.send
> --------------------------------------------------------------------------
>
>                 Key: AMQ-1517
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1517
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: JMS client
>    Affects Versions: 5.0.0
>            Reporter: Rob Davies
>            Assignee: Rob Davies
>             Fix For: 5.1.0
>
>
> We are using queue limits with a SEDA style architecture. We have certain queues which are machine specific in our storage solution so if the storage machine was to crash for whatever reason there is the possibility that our failure detection could happen after we have filled the queue up meaning we have deadlocked our workflow. It would be nice if we could put a timeout on a MessageProducer.send();
> The desired behavior for sending when queue limits are reached would be able to configure a producer to do any of the following three things:
> 1. Block until under the queue limit. This is current behavior. 
> 2. Have a timeout value. 
> 3. Throw an exception immediately.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.