[esb-issues] [JBoss JIRA] Commented: (JBESB-2551) Configure TTL on MessageProducer sending replies on behalf of RequestResponse pipelines

[Kevin Conner (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBESB-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12490919#action_12490919 ] 

Kevin Conner commented on JBESB-2551:
-------------------------------------

To clarify further, the 'default handling' refers to a default value for expiration rather than the explicit setting on the message as is currently handled.

Also, the name of the property can be referenced through JMSPropertiesSetter.JMS_EXPIRATION.


> Configure TTL on MessageProducer sending replies on behalf of RequestResponse pipelines
> ---------------------------------------------------------------------------------------
>
>                 Key: JBESB-2551
>                 URL: https://jira.jboss.org/jira/browse/JBESB-2551
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Transports
>    Affects Versions: 4.5
>            Reporter: Ryan Hochstetler
>
> When an external client sends a message via the ServiceInvoker to a RequestReponse service that takes longer than the client-configured timeout to reply, the reply message is still sent to the service's reply queue, but gets stuck, forever, since the courier that delivered the message did not configure a TTL on the MessageProducer or set the TTL on the MessageProducer's send() method.
> Add a property to jbossesb-properties.xml to hold the defined timout (zero for no TTL, if the original functionality is preferred.). Add hooks to the JmsCourier (and clients thereof) to set the TTL only on reply messages.  The courier is unlikely to know which messages are replies, but the clients of the courier should know well enough.
> This brings up an interesting point, now that I think of it.  In the event that the queue receiving the original message from the ServiceInvoker is backed-up, the ServiceInvoker will time-out before the original message is even picked up and inserted into a processing pipeline.  It seems to me that it would be better if the message would never be processed if the client has given up on waiting for the reply.  This way, we eliminate unintended consequences or mysterious behavior, where we tell the user that the request was not serviced, but in fact, the user sees evidence to the contrary in the system.  Perhaps the courier used by the ServiceInvoker should also set a TTL on the request mesage.  This TTL should probably be equal to the timeout passed to the deliverSync() method.  Of course, this would not be guaranteed behavior, as the message could be inserted into a pipeline just prior to the TTL, but the ServiceInvoker could still timeout.  The real benefit here would be that hundreds of sync messages wouldn't queue up and then be unleashed after a previously unavailable resource comes back online an hour later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira