In our current JDC implementation, we rely heavily on nested locking. While this is functionally correct and provides the necessary atomic guarantees, it does not scale well under very high-throughput workloads. In such scenarios, contention increases significantly, along with the risk of lock poisoning. We recently migrated part of the tproxy implementation to use DashMap (a concurrent hash map), and the performance improvement was substantial.
Going forward, we should refactor the JDC to adopt more appropriate concurrent data structures and reduce our dependence on deeply nested locks.
In our current JDC implementation, we rely heavily on nested locking. While this is functionally correct and provides the necessary atomic guarantees, it does not scale well under very high-throughput workloads. In such scenarios, contention increases significantly, along with the risk of lock poisoning. We recently migrated part of the tproxy implementation to use DashMap (a concurrent hash map), and the performance improvement was substantial.
Going forward, we should refactor the JDC to adopt more appropriate concurrent data structures and reduce our dependence on deeply nested locks.