camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: File consumer - waiting for it to start
Date Mon, 06 Feb 2012 06:09:44 GMT
On Sun, Feb 5, 2012 at 4:28 PM, Babak Vahdat
<> wrote:
> Hi Claus,
> with the usage of ScheduledBatchPollingConsumer and it's derivates inside
> routes there's an issue while doing context.stopRoute("myCoolRoute") as
> Camel tries to shutdown the route gracefully and as the mentioned class
> does:
>        if (answer == 0 && isPolling()) {
>            // force at least one pending exchange if we are polling as
> there is a little gap
>            // in the processBatch method and until an exchange gets
> enlisted as in-flight
>            // which happens later, so we need to signal back to the
> shutdown strategy that
>            // there is a pending exchange. When we are no longer polling,
> then we will return 0
>            LOG.trace("Currently polling so returning 1 as pending
> exchanges");
>            answer = 1;
>        }
> it waits and waits until the (30 seconds) timeout reaches although no *real*
> inflight exchanges are available at all! I realized this behavior as I was
> trying to provide a working example for the user (you see already by this
> thread).
> However doing main.stop() (as by the upper example) did *not* behave like
> this!
> A possible fix (may be dirty) would be to check that if we already returned
> X times a hard-coded value of 1 then we should better return 0 instead to
> signal there's no real inflight exchange available.

I was first against this as stopping a route from a route was in fact wrong.
And hence why the FAQ is updated etc.

However there is still this problem for people mistakenly using the
old approach.
We could hack as you suggested, but should we add hacks in the code
for bad practice?

If we add the hack, we must ensure that the state is cleared, when you
start the route again,
to avoid the state to be kept around.

Babak, feel free to open a JIRA and work on the hack if you fell like
we need it. But remember
to add code comments why we have this hack in the code. So when we
look at it again in 1+ years
we know why the hack is there.

> Babak
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message