[
https://issues.apache.org/jira/browse/CAMEL-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942927#comment-13942927
]
metatech edited comment on CAMEL-7308 at 3/21/14 10:05 AM:
-----------------------------------------------------------
Hi Claus, thanks for your review.
Beware that I needed to remove the check for "started" in the
"isTaskAllowedToRun" method, because the state is still "starting" at this
point.
It can be seen in the method "start" of class "ServiceSupport" :
- firstly "doStart" is called, where the "onCamelContextStarted" is called.
- secondly, "started.set(true)" is called.
My observation was that there was a race condition :
- if the "scheduleAtFixedRate" is very fast to run, the camel context is still
in "starting" state.
- if the "scheduleAtFixedRate" takes a few milliseconds longer to run, the
camel context will enter the "started" state before.
Typically, the timer was fired when I was connected with my debugger and not
fired without debugger, so I guess the race condition window is really small.
was (Author: metatech):
Hi Claus, thanks for your review.
Beware that I needed to remove the check for "started" in the
"isTaskAllowedToRun" method, because the state is still "starting" at this
point.
It can be seen in the method "start" of class "ServiceSupport" :
- firstly "doStart" is called, where the "onCamelContextStarted" is called.
- secondly, "started.set(true)" is called.
My observation was that there was a race condition :
- if the "scheduleAtFixedRate" is very fast to run, the camel context is still
in "starting" state.
- if the "scheduleAtFixedRate" takes a few milliseconds longer to run, the
camel context will enter the "started" state before.
Typically, the timer was fired when I was connected with my debugger and not
fired without debugger, so I guess the race condition window is really small.
> Timer component : timer should use StartupListener to be initialized before
> first fire
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-7308
> URL: https://issues.apache.org/jira/browse/CAMEL-7308
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.10.7
> Environment: ServiceMix 4.5.3
> Reporter: metatech
> Assignee: Claus Ibsen
> Fix For: 2.12.4, 2.13.1, 2.14.0
>
> Attachments: camel_timer_startuplistener.diff
>
>
> CAMEL-5542 creates a regression for our routes when migrating from ServiceMix
> 4.4 to ServiceMix 4.5.
> The secondary route in which we use this timer populates a cache, which must
> be initialized before other primary routes in the bundle can use it,
> otherwise requests sent to these other routes will generate errors.
> In our ServiceMix installation with all the other bundles, the bundle with
> the timer can take from 1 second to 30 seconds to start-up, depending on the
> machine speed and the number of other bundles which are installed/started at
> the same time.
> It is therefore very difficult to estimate the time to define for the "delay"
> variable. If set too low, the first fire will be ignored and the other
> primary routes will generate errors until the timer second fire. If set too
> high, the other primary routes will generate errors until the timer first
> fire.
> Normally the timer period is set to refresh the cache every several minutes,
> which leaves a large window where requests end with an error in case the
> cache failed to initialize.
> Here is a patch with a StartupListener which effectively reduces the window
> of errors to a fraction of a second.
> Also, it would help to debug these kind of problems if a "debug" log is added
> when the first timer fire is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
