[
https://issues.apache.org/jira/browse/RATIS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Pal resolved RATIS-2611.
---------------------------------
Resolution: Not A Bug
> Some gRPC install-snapshot replies don't clear the pending queue
> ----------------------------------------------------------------
>
> Key: RATIS-2611
> URL: https://issues.apache.org/jira/browse/RATIS-2611
> Project: Ratis
> Issue Type: Bug
> Reporter: Abhishek Pal
> Assignee: Abhishek Pal
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When calling the onNext method, in the various result cases
> [here|https://github.com/apache/ratis/blob/f4c3781468e756220836e88d953fd5598177afdf/ratis-grpc/src/main/java/org/apache/ratis/grpc/server/GrpcLogAppender.java#L676]
> some cases do not call `removePending()`.
> - NOT_LEADER
> - CONF_MISMATCH
> - UNRECOGNIZED
> - SNAPSHOT_EXPIRED
> these cases do not clear the pending queue and this may possibly fail on the
> Preconditions.assertSame() check.
> `pending.poll()` removes the oldest enqueued request index. The handler
> assumes that for each reply we will have one addPending() and then one
> removePending() call in order.
> So if we take an example of chunk install with `SNAPSHOT_EXPIRED`
> 1. Let us assume we send chunk [0,1,2] -> three `addPending()` calls ->
> pending queue [0, 1, 2]
> 2. Reply with chunk 0 as success -> one `removePending()` call ->
> pending.poll() returns 0, condition passed
> 3. Reply with chunk 1 as SNAPSHOT_EXPIRED -> pending queue still has [1, 2]
> This is not a critical bug as onError() a new handler is generated which
> causes stream teardown and that abandons the broken handler, but it would be
> good to fix this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
