I saw this and I completely understand it. my problem is not that router1 is waiting for initial request to complete (I'd like it to wait as my request is an InOut), but, I will like it to accept another request and respond to the appropriate endpoint (the one that initiated the request). That does not seem to be happening.
What is happening is that, router1 receives an initial request (and keep waiting for a response - which is fine), and receives another request and sends the output message from initial request as a response to the second request. Thats confusing, but it was what I got when I turned on the trace on the router. kr. Claus Ibsen-2 wrote: > > Well if you take your time to read the VM wiki page, you will notice > it extends the SEDA which offers options to configure the blocking > > http://camel.apache.org/vm > http://camel.apache.org/seda.html > > You can use waitForTaskToComplete to control the blocking behavior > > > On Thu, Mar 4, 2010 at 2:17 PM, lekkie <[email protected]> wrote: >> >> Are you saying that you route to "route1" 2 times? eg kinda like in a >> circle? >> >> You are right. The idea is to make router1 (which is a dynamic recipient >> EIP) to take messages and route to whichever endpoint. It is suppose to >> be a >> central endpoint. Collect msges route to the nxt endpoint and wait to >> collect response and send to original requester. >> >> I didnt expect the router to block when it has not got response from >> initial >> request (which is why I used vm). Is there a non blocking endpoint that >> can >> do this? >> >> I tried this and it worked. >> >> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >> trace="true"> >> <route> >> <from uri="nmr:consumerEndPoint"/> >> <loadBalance ref="roundRobinRef"> >> <to uri="vm:router1"/> >> <to uri="vm:router2"/> >> </loadBalance> >> </route> >> </camelContext> >> >> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >> trace="true"> >> <route> >> <from uri="nmr:someIntermediateEndPoint "/> >> <loadBalance ref="roundRobinRef"> >> <to uri="vm:router2"/> >> <to uri="vm:router1"/> >> </loadBalance> >> </route> >> </camelContext> >> >> >> >> Regards. >> >> >> Claus Ibsen-2 wrote: >>> >>> On Thu, Mar 4, 2010 at 8:50 AM, lekkie <[email protected]> wrote: >>>> >>>> I have a use case that requires a certain endpoint to be re-used. Lets >>>> say >>>> the re-usable endpoint is called router1. >>>> >>>> The flow below causes a blockage on my route and leads to camel >>>> throwing >>>> exception. >>>> >>>> consumerEndPoint -> router1 -> someIntermediateEndPoint -> router1`-> >>>> someProviderEndpoint ........ >>>> >>> >>> Are you saying that you route to "route1" 2 times? eg kinda like in a >>> circle? >>> >>> And what does your route1 recipient list do? >>> >>> All together I suggest to make your use case as simple as possible, to >>> get something working. >>> And then build from there. >>> >>> And you can change the MEP if you need. >>> >>>> >>>> This flow is an InOut exchange flow. What is happening is that, because >>>> the >>>> first message passes through router1 and it is still waiting for a >>>> response, >>>> router1` will wait forever. I think camel throws the exception below >>>> >>>> 08:29:12,569 | INFO | oLogger-thread-1 | Tracer >>>> | >>>> rg.apache.camel.processor.Logger 88 | >>>> c66c0dd3-657a-4508-9295-c6f6b6d64a02 >>>>>>> (route20) OnException[ExchangeTimedOutException] --> transform[ >>>> >>>> 08:29:12,569 | ERROR | oLogger-thread-1 | DefaultErrorHandler >>>> | >>>> rg.apache.camel.processor.Logger 202 | Failed delivery for exchangeId: >>>> c66c0dd3-657a-4508-9295-c6f6b6d64a02. Processed by failure processor: >>>> Channel[Transform( >>>> >>>> 08:29:33,653 | INFO | saction-thread-1 | Tracer >>>> | >>>> rg.apache.camel.processor.Logger 88 | >>>> c36c48b5-e18d-498e-9fed-b340e0baeb05 >>>>>>> vm://router1 --> OnException[ExchangeTimedOutException] <<< >>>> Pattern:InOut, Headers:{operationName=null, nmrMessage=Message []}, >>>> BodyType:String, Body: >>>> >>>> 08:29:33,653 | INFO | saction-thread-1 | Tracer >>>> | >>>> rg.apache.camel.processor.Logger 88 | >>>> c36c48b5-e18d-498e-9fed-b340e0baeb05 >>>>>>> (route23) OnException[ExchangeTimedOutException] --> transform[ >>>> >>>> 8:29:33,653 | ERROR | saction-thread-1 | DefaultErrorHandler >>>> | >>>> rg.apache.camel.processor.Logger 202 | Failed delivery for exchangeId: >>>> c36c48b5-e18d-498e-9fed-b340e0baeb05. Processed by failure processor: >>>> Channel[ >>>> >>>> >>>> Loadbalancer is not resolving this as it still ends up sending to same >>>> router. >>>> >>>> See my camel snippets below: >>>> >>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >>>> trace="true"> >>>> <route> >>>> <from uri="nmr:consumerEndPoint"/> >>>> <loadBalance ref="roundRobinRef"> >>>> <to uri="vm:router1"/> >>>> <to uri="vm:router2"/> >>>> </loadBalance> >>>> </route> >>>> </camelContext> >>>> >>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >>>> trace="true"> >>>> <route> >>>> <from uri="nmr:someIntermediateEndPoint "/> >>>> <loadBalance ref="roundRobinRef"> >>>> <to uri="vm:router1"/> >>>> <to uri="vm:router2"/> >>>> </loadBalance> >>>> </route> >>>> </camelContext> >>>> >>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >>>> trace="true"> >>>> <route> >>>> <from uri="nmr:someProviderEndPoint"/> >>>> <to uri="mock:whatever"/> >>>> </route> >>>> </camelContext> >>>> >>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >>>> trace="true"> >>>> <route> >>>> <from uri="vm:router1"/> >>>> <bean ref="router1ProcessorRecipientList" >>>> method="route"/> >>>> </route> >>>> </camelContext> >>>> >>>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"; >>>> trace="true"> >>>> <route> >>>> <from uri="vm:router2"/> >>>> <bean ref="router2ProcessorRecipientList" >>>> method="route"/> >>>> </route> >>>> </camelContext> >>>> >>>> >>>> >>>> What EIP would be the most appropriate for this scenario? >>>> >>>> kr. >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Blocked-endpoints%3A-What-EIP-%27d-be-most-appropriate--tp27777606p27777606.html >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Author of Camel in Action: http://www.manning.com/ibsen/ >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Blocked-endpoints%3A-What-EIP-%27d-be-most-appropriate--tp27777606p27780598.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > > -- View this message in context: http://old.nabble.com/Blocked-endpoints%3A-What-EIP-%27d-be-most-appropriate--tp27777606p27780828.html Sent from the Camel - Users mailing list archive at Nabble.com.
