[
https://issues.apache.org/jira/browse/RATIS-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wangqiang updated RATIS-2665:
-----------------------------
Description:
SegmentedRaftLogWorker polls its I/O task queue with a one-second timeout.
When close() is called while the worker is idle, it only sets running to false.
Since the worker is blocked in DataBlockingQueue.poll(), it cannot observe the
updated state until the poll times out. As a result, closing an idle
SegmentedRaftLogWorker may take up to one second.
This delay becomes significant when Raft groups are frequently created and
removed, since the delay is incurred for each group during shutdown.
The worker should be explicitly awakened during close without interrupting a
task that may be performing log I/O. A private wake-up task can be offered to
the queue after running is set to false. The worker recognizes this task and
exits before normal task execution, metrics, exception handling, or future
completion.
If the queue is full, offering the wake-up task may fail safely: the worker is
not blocked on an empty queue in that case and will observe running == false
after completing its current task.
was:
SegmentedRaftLogWorker polls its I/O task queue with a one-second timeout.
When close() is called while the worker is idle, it only sets running to false.
Since the worker is blocked in DataBlockingQueue.poll(), it cannot observe the
updated state until the poll times out. As a result, closing an idle
SegmentedRaftLogWorker may take up to one second.
This delay becomes significant when Raft groups are frequently created and
removed, since the delay is incurred for each group during shutdown.
The worker should be explicitly awakened during close without interrupting a
task that may be performing log I/O. A private wake-up task can be offered to
the queue after running is set to false. The worker recognizes this task and
exits before normal task execution, metrics, exception handling, or future
completion.
If the queue is full, offering the wake-up task may fail safely: the worker is
not blocked on an empty queue in that case and will observe running == false
after completing its current task.
This change:
* avoids waiting for the one-second poll timeout when the worker is idle;
* does not interrupt active flush or log-sync operations;
* does not change the public API or the shutdown behavior for active I/O;
* adds only an identity comparison to the normal task-processing path.
A regression test waits until the worker is blocked polling an empty queue and
verifies that close completes promptly. The test passed repeatedly and the
complete TestSegmentedRaftLog suite also passed.
> SegmentedRaftLogWorker close may wait for the task queue poll timeout
> ---------------------------------------------------------------------
>
> Key: RATIS-2665
> URL: https://issues.apache.org/jira/browse/RATIS-2665
> Project: Ratis
> Issue Type: Improvement
> Affects Versions: 3.2.2
> Reporter: wangqiang
> Assignee: wangqiang
> Priority: Major
>
> SegmentedRaftLogWorker polls its I/O task queue with a one-second timeout.
> When close() is called while the worker is idle, it only sets running to
> false.
> Since the worker is blocked in DataBlockingQueue.poll(), it cannot observe the
> updated state until the poll times out. As a result, closing an idle
> SegmentedRaftLogWorker may take up to one second.
> This delay becomes significant when Raft groups are frequently created and
> removed, since the delay is incurred for each group during shutdown.
> The worker should be explicitly awakened during close without interrupting a
> task that may be performing log I/O. A private wake-up task can be offered to
> the queue after running is set to false. The worker recognizes this task and
> exits before normal task execution, metrics, exception handling, or future
> completion.
> If the queue is full, offering the wake-up task may fail safely: the worker is
> not blocked on an empty queue in that case and will observe running == false
> after completing its current task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
