[英]Shutdown IdleConnectionReaper in AWS Java SDK v2
I'm using S3Client from Java SDK v2.我正在使用来自 Java SDK v2 的 S3Client。 to upload/download files from AWS S3 in a distributed web application.在分布式 web 应用程序中从 AWS S3 上传/下载文件。
I had a problem with idle-connection-reaper
daemon thread preventing/delaying the class from being unloaded during shutdown.我在idle-connection-reaper
守护线程阻止/延迟 class 在关闭期间被卸载时遇到问题。 I did some investigations and I figured out that in AWS Java SDK v1, this could be resolved by calling IdleConnectionReaper.shutdown()
method.我做了一些调查,发现在 AWS Java SDK v1 中,这可以通过调用IdleConnectionReaper.shutdown()
方法来解决。
I imported apache client to my project我将 apache 客户端导入到我的项目中
<!-- https://mvnrepository.com/artifact/software.amazon.awssdk/apache-client -->
<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>apache-client</artifactId>
<version>2.17.162</version>
</dependency>
And I would like to do the same thing using AWS Java SDK v2.我想使用 AWS Java SDK v2 做同样的事情。 The problem is that shutdown()
method is no longer static and exposed.问题是shutdown()
方法不再是 static 并且暴露了。
They changed the class to a Singleton and the only exposed APIs are:他们将 class 更改为 Singleton,唯一暴露的 API 是:
public synchronized boolean registerConnectionManager(HttpClientConnectionManager manager, long maxIdleTime)
public synchronized boolean deregisterConnectionManager(HttpClientConnectionManager manager)
deregisterConnectionManager()
calls shutdown internally but I don't know what HttpClientConnectionManager
I should give as an argument for both methods deregisterConnectionManager()
在内部调用 shutdown 但我不知道我应该为这两种方法提供什么HttpClientConnectionManager
作为参数
My question is: Is there another approach to shutdown that daemon thread or I should stick to the new implementation of IdleConnectionReaper
?我的问题是:是否有另一种方法可以关闭该守护程序线程,或者我应该坚持使用IdleConnectionReaper
的新实现? If so, what are exactly HttpClientConnectionManager
parameter in both registerConnectionManager
and deregisterConnectionManager
methods?如果是这样, registerConnectionManager
和deregisterConnectionManager
方法中的HttpClientConnectionManager
参数到底是什么?
You shouldn't need to interact with the v2 IdleConnectionReaper
anymore, and that's why the public interface has changed to reflect this.您应该不再需要与 v2 IdleConnectionReaper
交互,这就是为什么公共接口已更改以反映这一点。
There is a key difference between AWS Java SDK v1 & v2 in regards to the S3 client.就 S3 客户端而言,AWS Java SDK v1 和 v2 之间存在一个关键区别。
V1's AmazonS3Client
implements the AmazonS3
custom interface which provides the shutdown
method to be implemented. V1 的AmazonS3Client
实现了AmazonS3
自定义接口,该接口提供了要实现的shutdown
方法。
This wasn't enforced & was an optional method so I assume the daemon thread was needed to prevent leaks in case the S3 client was not closed at all anywhere.这不是强制执行的并且是一种可选方法,因此我假设需要守护线程来防止泄漏,以防 S3 客户端在任何地方都没有关闭。
V2's S3Client
implements the AutoClosable
interface, an inherent interface in java.lang
after version 7. V2 的S3Client
实现了AutoClosable
接口,这是java.lang
7 之后的固有接口。
With AutoClosable
, the AWS SDK is clearly communicating the expectation of your application managing the closing & cleanup of the S3 client.借助AutoClosable
,AWS SDK 清楚地传达了您的应用程序管理 S3 客户端关闭和清理的期望。 This is preferably done by delegating the closing of the client to the JVM by enclosing it in a try-with-resources statement or if needs be, explicitly via S3Client.close()
.这最好通过将客户端的关闭委托给 JVM 来完成,方法是将其包含在try-with-resources语句中,或者如果需要,通过S3Client.close()
明确地进行。
The AWS Java SDK v2 utilises newer features of the Java language & as such, it expects you to handle your resources correctly in line with modern Java development practices. AWS Java SDK v2 使用了 Java 语言的更新功能,因此,它希望您根据现代 Java 开发实践正确处理您的资源。
Close your S3 client objects (& object content streams.) correctly & you will be fine.正确关闭您的 S3 客户端对象(和 object 内容流。),您会没事的。
Just more analysis: The inner ReaperTask has a 1 minute sleep time during which it doesn't check its 'stopping' flag - hence it does not realize it should shut down.更多分析:内部 ReaperTask 有 1 分钟的睡眠时间,在此期间它不会检查其“停止”标志 - 因此它没有意识到它应该关闭。 However it will be interrupted/shut down once the last connection manager is reregistered.然而,一旦最后一个连接管理器被重新注册,它将被中断/关闭。
On my side the issue was using the SDK builder with an injected HttpClient (also built by an SDK builder).在我这边,问题是使用带有注入 HttpClient 的 SDK 构建器(也由 SDK 构建器构建)。 This causes a wrapper around it, preventing deregistering on close of the outer client.这会在它周围形成一个包装器,防止在关闭外部客户端时注销。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.