> In the case of OrderedExecutor, it needs a BlockingQueue and the current
> default is to use JDK LinkedBlockingQueue which relies on CAS for
> enqueue/dequeue. Additional room for improvement here is to use a more
> specialized MP-SC queue with different wait strategies.
+1 to this, though something to keep in mind here is that these aren't
BK's cores we're running on, they belong to the client application.
> Overall, I think we should still keep separated the critical data path from
> the rest of operations that are not necessarily time critical.
Keeping the scheduling threads and the executor threads separate means
that we need monitors, which can mean potential blocking, and other
threads invalidating the cpu cache of thread could potentially be kept
very warm.
>> What I want to achieve here is that, after a operation is submitted to
> a ledger, it only ever operates on a single thread.
>
> I think a viable option would be to keep the scheduler separate and then
> always jump in the ledger thread. eg:
>
> scheduler.schedule(() -> {
> executor.executeOrdered(ledgerId, SafeRunnable.safeRun(() -> {
> // do something
> });
> }, 100, TimeUnit.MILLISECONDS);
>
This is basically what I was suggesting, except that we hide this
behind the OrderedScheduler interface. Passing in both the scheduler
and the executor allows the user to run stuff on another thread
unwittingly.
-Ivan
