Consider allowing usage of virtual threads with Java >= 21

[eivanov89]

Hi,

We did a fork of benchbase to get TPC-C for YDB. Here we describe our testing setup and TPC-C implementation with a particular focus on the threading model.

We need to run 15K TPC-C warehouses and even more, which requires >= 150,000 terminals. Currently, you use the model where 1 terminal equals 1 thread, which is not optimal. Even with sleeping threads, it's hard to create more than 3-5K terminals per server. As of Java 21, virtual threads are available, and they are in many ways similar to goroutines. Transitioning to virtual threads involves straightforward code changes here. However, there might be some potential deadlocks depending on the particular JDBC driver and benchmark. For instance, when we added the c3p0 session manager, we encountered a deadlock. It was holding carrier threads waiting for sessions to become available, while session threads were parked for I/O and couldn't get carrier threads to perform I/O.

Is there any chance you would consider switching to Java 21 so that virtual threads become an option?

[bpkroth]

Hi, happy to accept a PR (even partial to get started with) if you have one. Thanks!

[eivanov89]

Hi Brian, I've created the pull request. The changes are straightforward. Looking forward the review.

[bpkroth]

FWIW, we bumped to java 21 a while back (and 23 today), but as I recall, there were some issues with switching to virtual threads.

I'll leave this open, but I'm going to check the title.

[eivanov89]

FWIW, we bumped to java 21 a while back (and 23 today), but as I recall, there were some issues with switching to virtual threads.

I'll leave this open, but I'm going to check the title.

Hi Brian,

Thank you for the update. Unfortunately, we (YDB) failed to allocate time to prepare a PR to the Benchbase repo. For the record:

1. We ended with two separate repos (TPC-C only): YDB and PostgreSQL.
2. The commits for Postgres might be reused by Benchbase.

The issue with virtual threads is that they cause deadlocks. In particular, we added the c3p0 pool manager to use with Postgres. Deep inside c3p0, carrier threads were blocking while waiting for new connections. As a result, there were no carrier threads available to finish ready requests and return connection objects to the pool. I fixed the issue by switching to Hikari.

[bpkroth]

Hi @eivanov89 thanks for the update.

Honestly, I'd love to have connection pooling support and read vs. write connection separation for replicated environments as well. Unfortunately, maintainership for this is a bit of a side gig for me atm. If you do find time to submit either of these or YDB support I'd be happy to help review them. My main sticking point is to make sure they have good tests to ensure we don't regress in the future without noticing.

Cheers!