Hi
Make sure you use the right parameter.
There is one for first time delay and another for time between next
triggers. So it sounds like you use 10 sec for first time, and then it uses
the default 1 s for the following
On Tue, Sep 2, 2025 at 1:48 PM Gabriel Souza <
gabrielaraujodesouz...@gmail.com> wrote:
> Hi, thanks for the clarification.
>
> We're currently in a situation where the route is being triggered every 1s,
> even though the configured period is 10s. We're trying to understand what's
> causing this. It's a microservice with only 1 pod instance. Do you have any
> suggestions for what to look at?
>
> Thanks in advance,
> Gabriel
>
> On Tue, Sep 2, 2025 at 2:19 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
>
> > Hi
> >
> > The timer is a single thread so the previous task needs to complete
> before
> > firing the next.
> > Read about the fixedRate option (its a JDK timer option).
> >
> > The synchronous option can allow the timer thread to complete sooner and
> be
> > available to fire next task,
> > but this is only happening if async process is happening later in the
> > routing.
> >
> > The long could in theory overflow, but that will take a gazillion years.
> >
> >
> >
> >
> > On Mon, Sep 1, 2025 at 9:28 PM Gabriel Souza <
> > gabrielaraujodesouz...@gmail.com> wrote:
> >
> > > Hello!
> > >
> > > We're using the Timer component, with below configuration:
> > >
> > > from("timer://foo?fixedRate=true&period=10000&synchronous=true")
> > > .to("bean:myBean?method=someMethodName");
> > >
> > > The question is, since we're using synchronous=true, what happens if
> the
> > > processing takes longer than 10s?
> > >
> > > In reality, we have a router that is much longer than this. And
> usually,
> > > the complete time from the firing of the event to finishing processing
> > the
> > > exchange is longer than the 10s defined in the period.
> > >
> > > Will Camel start another exchange even if the first didn't finish
> > > processing yet? Does the synchronous flag change something for that
> > matter?
> > >
> > > Also, the documentation Exchange.TIMER_COUNTER as the current fire
> > counter,
> > > and it's a Long. What happens if a process runs for long enough, is it
> > > possible that this variable overflows?
> > >
> >
> >
> > --
> > Claus Ibsen
> >
>
--
Claus Ibsen
