Some of the messages where handled by wrong service and they are all queued in FailedErrorMessages directory. Application failed to process them. So it will end up in ordering, and lost message. Looking at our various exception it is quite easy for us to understand that they are caused by concurrency bug inside the buz logic.
We like to move the <inOnly uri="direct://buzComponent" /> to new route under some endpoint (in-mem-queue). Quick google doesn't return anything related to multiplex, could you point me sample route? Can I create that multiplex in the new route under new endpoint. Thanks On Fri, Sep 6, 2013 at 12:35 AM, Christian Posta <christian.po...@gmail.com>wrote: > So what's the underlying concurrency issue? Ordering? Can you just have a > route that multiplexes all of those incoming queues into a single queue (or > in-mem queue) and then have a route w/ only one thread that does CBR and > invoke the correct bean? > > > On Thu, Sep 5, 2013 at 9:02 AM, gnani swami <projectnash1...@gmail.com > >wrote: > > > Hi, > > > > Camel was wonderful piece of software and using it in production for more > > than a year. Our version of Camel was 2.10.1 > > > > I recently added few additional route (and bug in buz logic too) to > > interface with additional systems, all the routes are doing the similar > > job. They read JMS message from an unique-end-point (MQ JMS Queue) and > > invoke buzComponent (Camel component). > > > > But recently discovered that some subtle concurrency issues inside the > > buzComponent causing trouble to us. And I am looking for some sort of > Camel > > hack to prevent it from further damage by making all the end-point > consumer > > to use one and only thread. > > > > 1) As a short term solution, we like to convert all the JMS component to > > use single threaded threadPool (or taskExecutor), and that new thread > pool > > shouldn't allow more than a thread across all the JMS end-point. Is it > > possible? We are not worried about latency and performance for some > time. > > > > 2) if there is a possibility, our camel error handlers were already > > in-place, Can we assume that single thread would continue working despite > > any exception configured to errorHandler. ErrorHandlers will have its own > > thread. > > > > 3) I am also happy to introduce one or more route and end-point inside > > camelcontex.xml, so all the buzComponent can be redirected into that new > > route to make it SingleThreaded execution somehow.. are there any > > suggestion to use some camel component (We could use any hack as long as > > configurable inside xml). > > > > I am pretty sure all the above approach may be short sighted, but looking > > for temporary solution which could work for few days. We are happy to > > modify Camel xml, than changing code and making it complex. > > > > I appreciate feedback. > > > > Regards > > Mohan > > > > <camelContext> > > <route id="route-one"> > > <from uri="ibmmq1:queue:fromSourceOne" /> > > <inOnly uri="direct://buzComponent" /> > > </route> > > <route id="route-two"> > > <from uri="ibmmq2:queue:fromSourceTwo" /> > > <inOnly uri="direct://buzComponent" /> > > </route> > > <!-- problematic root due to buzComponent locking--> > > <route id="high-speed-source-source-3"> > > <from uri="ibmmq3:queue:fromHighSpeedSourceOne" /> > > <inOnly uri="direct://buzComponent" /> > > </route> > > <route id="high-speed-source-source-4"> > > <from uri="ibmmq4:queue:fromHighSpeedSourceTwo" /> > > <inOnly uri="direct://buzComponent" /> > > </route> > > </camelContext> > > > > <bean id="ibmmq" class="org.apache.camel.component.jms.JmsComponent"> > > <property name="connectionFactory"> > > <bean class="com.ibm.mq.jms.MQConnectionFactory"> > > ... > > </bean> > > </property> > > </bean> > > > > > > -- > *Christian Posta* > http://www.christianposta.com/blog > twitter: @christianposta >
