[ https://issues.apache.org/activemq/browse/CAMEL-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55358#action_55358 ]
Claus Ibsen commented on CAMEL-1336: ------------------------------------ See CAMEL-2151 which has the base stuff in the camel-core for components which supports async request/reply can leverage. > Full support for async messaging and correlation > ------------------------------------------------ > > Key: CAMEL-1336 > URL: https://issues.apache.org/activemq/browse/CAMEL-1336 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core > Affects Versions: 1.5.0 > Reporter: Hadrian Zbarcea > Assignee: Hadrian Zbarcea > Fix For: Future > > > This is a feature that has been requested by users a few times, and it's time > to get addressed. > Camel does not really support 2x 1-way async messaging. It sorta does in > camel-jms, by sending a message to a queue and setting the "JMSCorrelationID" > header. For a ExchangePattern.InOut it immediately waits for a response (up > to a timeout period) and gets the reply and continues processing. > There are a few issues with this approach: > * this mechanism is not available across all camel components. There are > other camel components that support async 1 way messaging such as file/ftp, > mail, mina, cxf, etc. > * there can be no other processing between a message is sent and a reply is > received. > * the timeout value is short and keeps resources locked, we cannot have long > running transactions > My proposal is to: > * move the mechanism from jms into core (and improve it) > * use a correlation mechanism (that will be different for different > components, such as MessageID in camel-mail) to correlate inputs with > outputs. The correlation mechanism could be implicit or explicit. > * provide a storage for pending 2x 1-way async UOWs (multiple options > available) > A route would then look something like this: > {code} > from("direct.start") > .setHeader("reply-to", constant("hadr...@localhost; c...@localhost")) > .correlate(header("Message-ID")) > .to("smtp://some...@localhost?password=secret&to=other...@localhost") > from("pop3://hadr...@localhost?password=secret).correlate(header("Message-ID")) > .from("some-other-source") > .aggregate(header("foo")).to("direct:end"); > {code} > *note*: the multiple from(s). > * This also gives unlimited time for a reply to be received. > * I don't think support for acid transactions makes any sense in such case. > * The presence of correlate() in the pipeline causes automatic storage of the > uow > * The presence of correlate() after a from() causes the removal of the uow > from persistent store. > Any ideas? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.