Repository navigation
[Feature] Synchronized version of AwsCrt4aSigningAdapter #782
Description
Describe the feature
The feature request is for an implementation of the AwsCrt4aSigningAdapter that either uses synchronized signing method or employs non-daemon threads during signing operations.
Use Case
The current SigV4a signer is implemented asynchronously using CompletableFuture, which defaults to using daemon thread. However, in specific scenarios such as when Spark's ShutdownHookManager is active, these daemon threads can be prematurely interrupted, leading to potential issues.
Proposed Solution
An implementation of the AwsCrtV4aSigner that either uses synchronized signing method or employs non-daemon threads during signing operations.
Pseudo code
public class AwsSigner {
private static final ThreadFactory nonDaemonThreadFactory = new ThreadFactory() {
private final AtomicInteger threadCount = new AtomicInteger(0);
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(r);
t.setDaemon(false); // Set the thread as non-daemon
t.setName("AwsSignerThread-" + threadCount.getAndIncrement());
return t;
}
};
/**
* Signs an http request according to the supplied signing configuration
* @param request http request to sign
* @param config signing configuration
* @return future which will contain the signed request
*/
static public CompletableFuture<HttpRequest> signRequest(HttpRequest request, AwsSigningConfig config) {
CompletableFuture<HttpRequest> future = new CompletableFuture<HttpRequest>();
CompletableFuture<AwsSigningResult> result = AwsSigner.sign(request, config);
result.whenCompleteAsync((res, throwable) -> {
if (throwable != null) {
future.completeExceptionally(throwable);
} else {
future.complete(res.getSignedRequest());
}
}, Executors.newSingleThreadExecutor(nonDaemonThreadFactory));
return future;
}
}
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
Activity
bretambrose commentedon Apr 27, 2024
If you supply credentials in the configuration structure, signing is synchronous.
Beyond that, the threads used in CRT signing are not Java managed at all and likely never will be. It seems like the best bet is to use a Java SDK credentials provider (not a CRT credentials provider which is where the native threads are being used), acquire credentials and then sign using the resolved credentials synchronously.
noCharger commentedon Apr 27, 2024
@bretambrose Thanks for the reply! Regarding the sigv4 use case, we currently utilize
com.amazonaws.auth.AWSCredentialsProvideralong withcom.amazonaws.auth.AWS4Signer. For the sigv4a signer, however, the interfacesoftware.amazon.awssdk.authcrt.signer.AwsCrtV4aSigneris provided asSdkHttpFullRequest sign(SdkHttpFullRequest request, ExecutionAttributes executionAttributes);. Could you demonstrate how to incorporate credentials into the configuration structure? I am eager to develop a customized version of the AwsCrt4aSigningAdapter that directly interfaces with AwsSigner.