[
https://issues.apache.org/jira/browse/CASSANDRA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759143#action_12759143
]
Jonathan Ellis commented on CASSANDRA-455:
------------------------------------------
scheduleAtFixedRate "Creates and executes a periodic action that becomes
enabled first after the given initial delay, and subsequently with the given
period; that is executions will commence after initialDelay then
initialDelay+period, then initialDelay + 2 * period, and so on. If any
execution of the task encounters an exception, subsequent executions are
suppressed..."
so get() shouldn't be causing a cancel, but if an exception is found then we
need to re-schedule it manually. (If you cast the Runnable in afterExecute to
ScheduledFutureTask you can get access to the scheduling info.)
if get is causing the cancel even w/o any exceptions being involved then I
guess you'll need to source dive in ScheduledThreadPoolExecutor to see what is
going on.
> DebuggableScheduledThreadPoolExecutor only schedules a task once
> ----------------------------------------------------------------
>
> Key: CASSANDRA-455
> URL: https://issues.apache.org/jira/browse/CASSANDRA-455
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.5
> Reporter: Jun Rao
>
> DebuggableScheduledThreadPoolExecutor only schedules a task exactly once,
> instead of periodically. This affects scheduled flushers and periodic hints
> delivery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
