Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Expected Behavior of Abort with the AWS JDBC Wrapper #1173

Closed
kiichiro-ito opened this issue Oct 31, 2024 · 5 comments · Fixed by #1182
Closed

Expected Behavior of Abort with the AWS JDBC Wrapper #1173

kiichiro-ito opened this issue Oct 31, 2024 · 5 comments · Fixed by #1182
Assignees
Labels
bug Something isn't working pending release Resolution implemented, pending official release

Comments

@kiichiro-ito
Copy link

I'm developing an application that connects to PostgreSQL via JDBC using Spring Boot and HikariCP.

When attempting to stop the application (sending SIGINT) while a long-running query is active, it seems that HikariCP waits for the query to complete before aborting the connection. This behavior appears to be related to the AWS JDBC Wrapper's implementation:
(https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/wrapper/src/main/java/software/amazon/jdbc/util/WrapperUtils.java#L186)

In contrast, when using only the standard PostgreSQL driver, the connection is forcibly terminated even if a long-running query is in progress.

Question:
Is there a configuration or method to avoid this behavior?
According to the java.sql.Connection#abort specification, the connection should be forcibly terminated.

Thank you.

@aaron-congo
Copy link
Contributor

aaron-congo commented Nov 6, 2024

Hi @kiichiro-ito, thank you for reaching out and raising this issue. Could you please clarify whether you are interrupting the long-running query with Connection.abort or by executing kill -SIGINT <PID> on the command line? I'm assuming the former, since from my testing kill -SIGINT<PID> ends the application immediately but Connection.abort with our wrapper driver seems to wait until the query finishes like you mentioned. Let me know, and in the meantime I will keep investigating. Thanks!

@aaron-congo aaron-congo self-assigned this Nov 6, 2024
@kiichiro-ito
Copy link
Author

kiichiro-ito commented Nov 7, 2024

Hi @aaron-congo. Thanks for your response!

I'm sending kill -SIGINT <PID> to a Spring Boot application, which ultimately triggers Connection.abort.

When Spring Boot receives a SIGINT, SpringApplicationShutdownHook runs in the background. This hook initiates the shutdown process, which calls HikariDataSource.shutdown and eventually leads to Connection.abort.

Below is a thread dump captured during this behavior.

"SpringApplicationShutdownHook" #16 prio=5 os_prio=0 cpu=15.62ms elapsed=11.09s tid=0x000002070f1bb730 nid=0x55e0 waiting on condition  [0x000000a528ffe000]
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(java.base@17.0.8.1/Native Method)
        - parking to wait for  <0x00000006092d2bd0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(java.base@17.0.8.1/LockSupport.java:211)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.8.1/AbstractQueuedSynchronizer.java:715)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.8.1/AbstractQueuedSynchronizer.java:938)
        at java.util.concurrent.locks.ReentrantLock$Sync.lock(java.base@17.0.8.1/ReentrantLock.java:153)
        at java.util.concurrent.locks.ReentrantLock.lock(java.base@17.0.8.1/ReentrantLock.java:322)
        at software.amazon.jdbc.ConnectionPluginManager.lock(ConnectionPluginManager.java:158)
        at software.amazon.jdbc.util.WrapperUtils.executeWithPlugins(WrapperUtils.java:234)
        at software.amazon.jdbc.util.WrapperUtils.runWithPlugins(WrapperUtils.java:165)
        at software.amazon.jdbc.wrapper.ConnectionWrapper.abort(ConnectionWrapper.java:180)
        at com.zaxxer.hikari.pool.HikariPool.abortActiveConnections(HikariPool.java:535)
        at com.zaxxer.hikari.pool.HikariPool.shutdown(HikariPool.java:230)
        - locked <0x0000000609b8abc0> (a com.zaxxer.hikari.pool.HikariPool)
        at com.zaxxer.hikari.HikariDataSource.close(HikariDataSource.java:351)
        at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:232)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:587)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:559)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:1202)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:520)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:1195)
        at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1183)
        at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1144)
        at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:1090)
        at org.springframework.boot.SpringApplicationShutdownHook.closeAndWait(SpringApplicationShutdownHook.java:145)
        at org.springframework.boot.SpringApplicationShutdownHook$$Lambda$857/0x00000206ca5cfc08.accept(Unknown Source)
        at java.lang.Iterable.forEach(java.base@17.0.8.1/Iterable.java:75)
        at org.springframework.boot.SpringApplicationShutdownHook.run(SpringApplicationShutdownHook.java:114)
        at java.lang.Thread.run(java.base@17.0.8.1/Thread.java:833)

Maven dependencies:

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>3.3.0</version>
		<relativePath /> 
	</parent>
	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-aop</artifactId>
		</dependency>
		<dependency>
			<groupId>org.mybatis.spring.boot</groupId>
			<artifactId>mybatis-spring-boot-starter</artifactId>
			<version>3.0.3</version>
		</dependency>		
		<dependency>
			<groupId>org.postgresql</groupId>
			<artifactId>postgresql</artifactId>
			</dependency>
		<dependency>
			<groupId>software.amazon.jdbc</groupId>
			<artifactId>aws-advanced-jdbc-wrapper</artifactId>
			<version>2.4.0</version>
		</dependency>
	</dependencies>

thank you.

@aaron-congo
Copy link
Contributor

Hi @kiichiro-ito,

We have just merged in a fix. Could you kindly checkout our latest snapshot build and let us know if the issue still persists?

Thank you!

@aaron-congo aaron-congo added the pending release Resolution implemented, pending official release label Nov 15, 2024
@kiichiro-ito
Copy link
Author

Hi @aaron-congo,

I tested it with the snapshot, and it's working as expected now.
Thanks for the fix!

@karenc-bq karenc-bq added the bug Something isn't working label Nov 22, 2024
@aaron-congo
Copy link
Contributor

Hi @kiichiro-ito ,

The fix is now available in the recently released v2.5.3 of the driver, so I will close this ticket now. Please feel free to open another ticket if you encounter any issues.

Thank you!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working pending release Resolution implemented, pending official release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants