True enough. I've had to deal with that before by using an aggregator and
assigning sequential numbers to the records as they go through and the
aggregate the results. Obviously that won't work if the records have to be
processed in the exact order they come in and not just written out in the
same order. I did in the case of processing credit cards where the
transactions could go in any order but they wanted the results written back
out in the same order they came in in the input file. One of the files had
a footer that came in and had to be written out as a footer so the
aggregation was important for that.
<unmarshal ref="recordsIn" />
<split>
<simple>${body}</simple>
<setHeader headerName="seqnum">
<simple>exchangeProperty.CamelSplitIndex</simple>
</setHeader>
<to uri="seda:processRecordsQueue" />
</split>
On Thu, Sep 1, 2016 at 2:08 PM, Quinn Stevenson <qu...@pronoia-solutions.com
> wrote:
> I’d be careful with configuring the number of consumers on the SEDA queue
> if you need to preserve order - you’ll likely get stuff processed
> out-of-order.
>
>
> > On Sep 1, 2016, at 1:00 PM, Brad Johnson <brad.john...@mediadriver.com>
> wrote:
> >
> > I'd second what Quinn said. The other nice thing about the SEDA queue is
> > you can directly configure the number of threads that are consuming from
> it.
> >
> > On Thu, Sep 1, 2016 at 1:50 PM, Quinn Stevenson <
> qu...@pronoia-solutions.com
> >> wrote:
> >
> >> When I’ve hit situations like this, I’ve used the SEDA component to
> >> serialize the processing after the message was received. All of the
> >> processing winds up in the SEDA route, and the actual receiving route
> (in
> >> this case, from Netty) just calls the SEDA route. Something like
> >>
> >> <route id=“receiver”>
> >> <from uri=“netty://…..>
> >> <to “seda://do-work>
> >> </route>
> >>
> >> <route id=“serial-processor”>
> >> <from uri=“seda://do-work <seda://do-work>>
> >> <bean id=“processor” method=“process” />
> >> <to uri=“destination://…” />
> >> </route>
> >>
> >>
> >>> On Aug 17, 2016, at 8:47 AM, Vitalii Tymchyshyn <v...@tym.im> wrote:
> >>>
> >>> You would need a combination.
> >>>
> >>> Ср, 17 серп. 2016 09:41 користувач robina <rashcr...@fomltd.com> пише:
> >>>
> >>>> Thanks for the reply Vitalii,
> >>>>
> >>>> Would setting synchronous=true on its own ensure that only one message
> >> is
> >>>> processed by the route at any given time? Or is it the combination of
> >> the
> >>>> maxPoolSize of 1 and synchronous=true setting?
> >>>>
> >>>> Regards,
> >>>> Rob
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://camel.465427.n5.nabble.com/Disabling-concurrency-in-
> >> camel-route-tp5786531p5786533.html
> >>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>>
> >>
> >>
>
>
