-
Notifications
You must be signed in to change notification settings - Fork 73
Description
Describe the bug
When virtual threads are used, blocking Socket operations can be interrupted and the Socket API will throw a SocketException with thread interrupt status set. Though this is a SocketException, and the underlying socket is closed (i.e. the connection is not usable), this should not initiate a failover.
Expected Behavior
Interrupting a virtual thread that's blocked while executing a query shouldn't initiates a failover.
What plugins are used? What other connection properties were set?
efm,failover,failover2
Current Behavior
When a virtual thread is interrupted, it initiates a failover in both failover and failover2 plugins.
Reproduction Steps
In Spring Boot app running on JDK 21, boundedElastic uses virtual threads.
inal var subscription = Mono.fromRunnable(() -> {
this.jdbcClient.sql("SELECT pg_sleep(100);")
.query()
.singleValue();
}
)
.subscribeOn(Schedulers.boundedElastic())
.subscribe();
TimeUnit.MILLISECONDS.sleep(100);
subscription.dispose(); // cancelling the Mono interrupts the virtual thread, throws SocketException, initiates a failover.Possible Solution
When the Failover plugin checks if it should initiate a failover, it should check if the cause is a SocketException and the current thread is interrupted, then this is not a real network failure, and shouldn't initiate a failover. Something like this:
protected boolean shouldExceptionTriggerConnectionSwitch(final Throwable t) {
if (t instanceof final SQLException sqlException &&
sqlException.getCause() instanceof SocketException &&
Thread.currentThread().isInterrupted()) {
return false;
}
...Additional Information/Context
No response
The AWS Advanced JDBC Driver version used
2.5.4
JDK version used
openjdk version "21.0.6" 2025-01-21 LTS
Operating System and version
Linux, macOS