Hi
The aggregator is a stateful pattern, which means that when the
message has been accepted by the aggregator, that route will continue
routing; and thus why the consumer does not "wait" for the aggregator.
If you want to learn more about this eip in detail then check the
Camel docs, and the Camel in Action book has extensive coverage of
this pattern in chapter 8.
On Sat, Dec 14, 2013 at 5:41 PM, ads_green <ads_gr...@hotmail.com> wrote:
> Hi All,
>
> When using the SQL component as a consumer, I can't seem to stop it from
> polling before the whole pipeline has finished. Instead it polls immediately
> after the last message has been accepted as a message.
>
> Consider:
>
> .from("sql:select * from
> a?dataSource=#datasource&maxMessagesPerPoll=3&consumer.useFixedDelay=true)
> .aggregate(constant(true),
> listStrategy).completionSize(5).completionTimeout(1000)
> ... more steps.
>
> As the aggregator is set to accept 5 messages, the first 3 returned from the
> sql consumer are accepted and then the aggregator returns allowing the sql
> to continue again.
>
> The process I am trying to define is:
> - read some rows from a database table. there may be 0 or more rows.
> - group the individual rows into batches of up to 5
> - send asynchronously to other steps in the queue. At the end of the process
> the successful rows will be deleted...
>
> Is there any way to prevent the sql client from re-polling until all the
> messages in the previous poll have completed successfully? I've tried
> "useFixedDelay=true" but the aggregator taking the messages seems to make
> the sql consumer
>
> thanks
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Parallel-processing-and-SQL-Consumer-tp5744778.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io
