[
https://issues.apache.org/jira/browse/ARTEMIS-2926?focusedWorklogId=505109&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-505109
]
ASF GitHub Bot logged work on ARTEMIS-2926:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 27/Oct/20 08:47
Start Date: 27/Oct/20 08:47
Worklog Time Spent: 10m
Work Description: franz1981 edited a comment on pull request #3287:
URL: https://github.com/apache/activemq-artemis/pull/3287#issuecomment-717082441
@gemmellr
A couple of observations on the changes on be3c193 on
https://github.com/apache/activemq-artemis/blob/be3c193f73775b961f855e6d935c442e28a14875/artemis-commons/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQScheduledComponent.java#L324-L331
I've chosen on purpose to allow a racing booking request (can be either from
a `delay` or the next periodic task submission on `executor`) to happen before
instead of on completion of `ActiveMQScheduledComponent.this.run()`:
- because of the expected behaviour of `delay`:
eg `JDBCJournalImpl` submit some records and call `syncTimer.delay()`; it
means that if a pending task hasn't yet
hit`bookedForRunning.compareAndSet(true, false)`, the delay request will fail,
leaving some records to not be picked up and processed later
- because of the uselessness (due to how a JVM work?) to detect a "slow" (ie
which execution time is > period) pending task (see
https://issues.apache.org/jira/browse/ARTEMIS-2926?focusedCommentId=17212908&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17212908):
TLDR if `bookedForRunning.compareAndSet(true, false)` takes long time to be
hit it doesn't mean that the task hasn't been prompty executed/is slow ->
skipping the next period task just means we're slowing down rate!
I've (by default) added a guard to save tasks to accumulate on the
`executor` or on the `scheduledExecutorService` (due to `delay`), but this can
be disabled for specific cases.
Although seems dangerous this guard is fine because a delay to start the
current task just means that is pointless to submit new ones, given that any
pending jobs will be picked by the current one when it will start.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 505109)
Time Spent: 40m (was: 0.5h)
> Scheduled task executions are skipped randomly
> ----------------------------------------------
>
> Key: ARTEMIS-2926
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2926
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.13.0
> Reporter: Apache Dev
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Scheduled tasks extending {{ActiveMQScheduledComponent}} could randomly skip
> an execution, logging:
> {code}
> Execution ignored due to too many simultaneous executions, probably a
> previous delayed execution
> {code}
> The problem is in the "ActiveMQScheduledComponent#runForExecutor" Runnable.
> Times to be compared ({{currentTimeMillis()}} and {{lastTime}}) are taken
> inside the runnable execution itself. So, depending on relative execution
> times, it could happen that the difference is less than the given period
> (e.g. 1 ms), resulting in a skipped execution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
