[
https://issues.apache.org/jira/browse/CAMEL-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607583#comment-13607583
]
Matt Pavlovich commented on CAMEL-6180:
---------------------------------------
By default if you have:
<from uri="amq:queue:MY_QUEUE" />
<to uri="mq:queue:MY_QUEUE"/>
and send a message with a JMSReplyTo header set, Camel automatically assumes
that you want Camel to handle the response, and that the response is going to
come in less time than the default exchange wait timeout.
This complicates things for a number of reasons:
1. If the route is just a proxy, you have to add a bunch of flags to get Camel
to not handle the response and preserve the QoS headers..
?disableReplyTo=true&preserveMessageQos=true. IMHO, if you are doing
synchronous request-reply over queues, that setting it explicitly would be a
better experience for users.
2. Many times, request-reply messaging patterns are two asynchronous routes,
and not one single integration point.
3. It complicates the connection pool management, as now you have producers
and consumers sharing pools and blocking each other out.. it gets messy in high
volumes+high connection count scenarios.
My suggestion would be to have requestReply be explicitly set via some url
paramater on the endpoint:
<from uri="..some InOut MEP component..">
<to uri="mq:queue:MY_REQUEST?replyToType=TemporaryQueue" />
Hope this helps.
Thanks,
Matt Pavlovich
> SJMS Component behavior suggestions to improve upon the standard JMS component
> ------------------------------------------------------------------------------
>
> Key: CAMEL-6180
> URL: https://issues.apache.org/jira/browse/CAMEL-6180
> Project: Camel
> Issue Type: Improvement
> Components: camel-sjms
> Reporter: Matt Pavlovich
> Assignee: Scott England-Sullivan
>
> The SJMS component should not suffer any feature loss from the standard JMS
> component, for best user experience in 3.0.
> A random mix of suggested behavior changes/enhancements:
> 1. Supporting things like consume from multiple destinations using
> wildcards... from jms:queue:US_TICKETS_*
> 2. Support dynamic destination on a <to uri=".." by using the same header
> from the existing JMS component.
> CamelJmsDestination javax.jms.Destination A destination object.
> CamelJmsDestinationName String The destination name.
> 3. I suggest making 'request-reply' be explicit, since implicit is really
> painful for new users. The "magic" temp destination listener is not confusing
> and the user has nothing in the route to go on as to why that is happening.
> 4. Along w/ #3, don't kill the QoS headers by default. It makes setting up
> proxies really complicated.
> 5. Support MQ Series 'weirdness' that current component handles.. see
> 'Setting JMS provider options on the destination' here:
> http://camel.apache.org/jms.html
> Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
