Hello Zuff! Please find some comments inline.
If your response take so long (7 hours), InOut MEP is definitely the wrong choice. You should use the InOnly MEP in your context a), b) and c). a) xxx -->activemq:topic:request activemq:topic:response1 --> Aggregator activemq:topic:response2 --> Aggregator --> yyy b) activemq:topic:request --> activemq:topic:response1 c) activemq:topic:request --> activemq:topic:response2 Something like this... And you should set the CorrelationID in context a). In this case, the Aggregator can use it to aggregate the responses... Best, Christian On Mon, Oct 8, 2012 at 11:24 AM, zuff <[email protected]> wrote: > Hi Christian, > > Thanks for the prompt reply. After discussion we have decided to go with > the temp-queue as suggested. > > However, I have some clarification to make. > > 1. There are actually 2/3 camel-contexts running. > a. One of the camel-context is runnnig in an deployed EAR > project, > that publishing to the "activemq:topic:request" > b. There is another server that is running a standalone > camel-context that is consuming from the "activemq:topic:request" > c. There is actually another camel-context (dummy) that's simply > consuming "activemq:topic:request", simulating a third client that will be > developed in future. > > 2. Therefore if camel context b and camel context c is down. I believe > it > is still possible for camelcontext a to publish a message to the activeMQ > broker? > Yes. > However is it possible for it to receive its JMSID, JMS Correlation ID, as > I > believe being a durable topic, camel-context b and camel-context c will > receive the message once the are online again. > You have to use a durable subscriber, not (only) a durable topic... > > > ___________________________________________________________________________________________________________________ > > Currently after changing my current design, I am facing some issues with > TemporaryQueueReplyManager. > > Note: The sequence that is received in route id="receiveRequest" is > not > gurantee to be the same as the sequence returned from > route id="sendResponse". e.g. > > I could be receiving 3 independent requests "ID 1", "ID 2", "ID 3" > on > the receiveRequest, however route id "sendResponse", I might be receibing > "ID 2", "ID 1", "ID 3". Each of these 3 independent need to be replied to > its respective JMSReplyTo as it is coming from different web client. > > <route id="receiveRequest"> > <from uri="active:topic:request"/> > <to uri="log:foo"/> > <multicast> > <bean ref="eventProcessor" method="processEvent"/> > <bean ref="exchangeUtil" method="add"/> > <constant>JMSReplyTo</constant> > </setProperty> > <setProperty propertyName="JMSCorrelationID"> > <constant>JMSCorrelationID</constant> > </setProperty> > <bean ref="strategyManager" > method="isStrategyComplete(${property.result})"/> > <choice> > <when> > <simple>${body}</simple> > <bean ref="camelJMS" > method="requestCompleted(${property.result})"/> > <setHeader> > <method ref=exchangeUtil" > method="get(${property.result},${property.JMSReplyTo})"/> > </setHeader> > <setHeader> > <method ref=exchangeUtil" > method="get(${property.result},${propertyJMSCorrelationID})"/> > </setHeader> > <to uri="log:foo"/> > </when> > </choice> > </route> > > Qn : > 1. How do I make sure I'm replying to the correct JMSReplyTo in a more > intelligent manner? > 2. I am also facing a Timeout on TemporaryQueueReplyManager as the Out > Message exceed 20000millisecond. > However shortly, i am getting an WARNING that a response was received > but of unknown CorrelationID. > Is it possible to remove the timeout limit as I might need to wait as > long as 7 hours for a reply before Route 2 is triggered. > I hope there wont be a blocking call between route id="receiveRequest" > and route id="sendResponse", and could handle any incoming messages. > > > Will appreciate any advise, or kindly point out any of the misconception > that I had. > > Thanks and Best Regards, > Zuff > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Best-Practise-for-Dynamic-Topic-in-Ear-Project-tp5720288p5720726.html > Sent from the Camel - Users mailing list archive at Nabble.com. > --
