Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Settable implementation in RAFT is not friendly to the StateMachine when current thread is interrupted #308

Closed
yfei-z opened this issue Sep 12, 2024 · 3 comments

Comments

@yfei-z
Copy link
Contributor

yfei-z commented Sep 12, 2024

When calling setAsync in leader node, the RAFT will be called directly by current thread, because there is a BlockingQueue.put operation in the process, that make the process interruptible, and the InterruptedException is not thrown out, instead return a CompletableFuture that never be completed. It only happens on leader node but not followers since there is no interruptible operations in followers. I think either making the setAsync uninterruptible or throwing out the InterruptedException are both OK, that makes the StateMachine easier to control its methods are interruptible or not.

@jabolina
Copy link
Member

Makes sense to me. I would return a CompletableFuture.failedFuture(exception) instead of adding a checked exception. The internal queue is something I had in mind to re-work in the future when time is available. So I wouldn't expose the exception for callers.

@yfei-z
Copy link
Contributor Author

yfei-z commented Sep 13, 2024

How about use non-blocking interface instead, the failure result returns immediately if there is no space, that make a consistent result for both leader and follower nodes, and avoid to handle a uncontrolled interrupted status of external thread.

            if (!processing_queue.offer(request)) {
                retval.completeExceptionally(new IllegalStateException("processing queue is full"));
                return retval;
            }

@jabolina
Copy link
Member

Unfortunately, we can't do that right now. The processing queue is shared for user requests and RAFT messages. This means we could drop internal messages without retrying. We have plans to split the queue in the future. Issue #168 also gives some more details on other issues.

The simplest change (for now) is to complete the operation if the put request fails.

yfei-z pushed a commit to yfei-z/jgroups-raft that referenced this issue Sep 25, 2024
* Complete user requests exceptionally if failed to add to the
  processing queue.

Closes jgroups-extras#308.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants