camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gnani swami <projectnash1...@gmail.com>
Subject Re: Are there any Camel hack to make all the JMS component to use one and only thread?
Date Sat, 07 Sep 2013 01:30:09 GMT
Thanks a lot!
It just worked.


On Fri, Sep 6, 2013 at 10:34 PM, Christian Posta
<christian.posta@gmail.com>wrote:

> +1 Andreas' comment.
>
> So what i was thinking was something like this...
>
> from("ibmmq1").to("seda:stage")
> from("ibmmq2").to("seda:stage")
> from("ibmmq3").to("seda:stage")
>
> from("seda:stage?concurrentConsumesr=1").to("direct://buzComponent")
>
>
>
>
> On Fri, Sep 6, 2013 at 3:57 AM, Andreas Gies <andreas@wayofquality.de
> >wrote:
>
> > One thing to keep in mind when you are experiencing odering issues is
> > that you can use ActiveMQ's message groups to make all messages for
> > one group to the same consumer. Very often that little trick helps
> > and still allows some form of concurrency for different groups.
> >
> > Andreas
> >
> >
> > On 09/05/2013 11:54 PM, gnani swami wrote:
> >
> >> 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.posta@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 <projectnash1994@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<
> http://www.christianposta.com/blog>
> >>> twitter: @christianposta
> >>>
> >>>
> >
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message