Add a stress test to RaftTest: the leader should call setAsync() 1M times; this mimics a stress test where the sender uses an async API (e.g. AsyncCounter) and does not use thenCombine() on the returned CompletionStage, but instead adds it to a list and joins all completion stages at the end of the test.
This should show the following issues:
- The max size of
processing_queue (default: 9182) will be reached immediately by the sender, filling the queue with DownRequests
UpRequests are far and few between, and will be handled very infrequently, as the sender always fills the queue- The problem is that
UpRequests are acks from followers, so pending requests will not be able to finish for a long time, possibly timing out
A possible solution (separate issue) would be to create 2 queues: a down- and an up-queue. The up-queue would always have to be processed first, in order to not starve up-requests. Note that this issue exists only on the leader, as followers have no elements in the down-queue.
Add a stress test to
RaftTest: the leader should callsetAsync()1M times; this mimics a stress test where the sender uses an async API (e.g.AsyncCounter) and does not usethenCombine()on the returnedCompletionStage, but instead adds it to a list and joins all completion stages at the end of the test.This should show the following issues:
processing_queue(default:9182) will be reached immediately by the sender, filling the queue withDownRequestsUpRequestsare far and few between, and will be handled very infrequently, as the sender always fills the queueUpRequestsare acks from followers, so pending requests will not be able to finish for a long time, possibly timing outA possible solution (separate issue) would be to create 2 queues: a down- and an up-queue. The up-queue would always have to be processed first, in order to not starve up-requests. Note that this issue exists only on the leader, as followers have no elements in the down-queue.