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
Currently, the SimpleDequePool#drainLoop calls AbstractPool.Borrower#deliver for all the pending acquisitions on behalf of one thread that wins the race to increment the WIP flag.
There are two issues with this approach:
The deliver method calls actual.onNext(poolSlot) on the current Thread and whatever happens next is executed on behalf of the Thread that either requested a connection or a Thread that obtained a connection. That means that instead of using the event loop associated with the connection to evenly distribute the load, potentially a requestor's Thread is used and can lead to bottlenecks.
In highly concurrent scenarios when multiple Threads attempt to obtain an established connection from the pool, only one of them wins the WIP CAS comparison to gain exclusive access to deliver all the connections. And that happens on a single core.
The solution to both problems in reactor-netty is to instantly offload the following work with the connection onto its associated event loop. However, in case of r2dbc's drivers, they don't necessarily have the means to offload the work and instead fall into both problematic cases described above. In consequence limiting their scalability significantly.
The aim of this report is to research means to offload the delivery to different execution runtime that can be associated with the POOLABLE resource. Therefore, abstracting the strategy reactor-netty is performing in order to make it a recognized solution that other implementations can leverage.
The text was updated successfully, but these errors were encountered:
Currently, the
SimpleDequePool#drainLoop
callsAbstractPool.Borrower#deliver
for all the pending acquisitions on behalf of one thread that wins the race to increment theWIP
flag.There are two issues with this approach:
deliver
method callsactual.onNext(poolSlot)
on the current Thread and whatever happens next is executed on behalf of the Thread that either requested a connection or a Thread that obtained a connection. That means that instead of using the event loop associated with the connection to evenly distribute the load, potentially a requestor's Thread is used and can lead to bottlenecks.WIP
CAS comparison to gain exclusive access to deliver all the connections. And that happens on a single core.The solution to both problems in reactor-netty is to instantly offload the following work with the connection onto its associated event loop. However, in case of r2dbc's drivers, they don't necessarily have the means to offload the work and instead fall into both problematic cases described above. In consequence limiting their scalability significantly.
The aim of this report is to research means to offload the delivery to different execution runtime that can be associated with the
POOLABLE
resource. Therefore, abstracting the strategy reactor-netty is performing in order to make it a recognized solution that other implementations can leverage.The text was updated successfully, but these errors were encountered: