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
