You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 withDownRequests
UpRequests
are far and few between, and will be handled very infrequently, as the sender always fills the queueUpRequests
are 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.
The text was updated successfully, but these errors were encountered: