I placed the jar generated by Maven build in S3 and used it as the execution source of Lambda function. Each function class was described as a definition in the state machine of StepFunctions, and the state machine was called via CloudWatchEvent. Each class implemented RequestHandler, but among them, only the process that refers to S3 ** caused the error as the title.
java.lang.NoSuchFieldError: SIGNING_REGION
at com.amazonaws.services.s3.AmazonS3Client.createRequest(AmazonS3Client.java:4660)
at com.amazonaws.services.s3.AmazonS3Client.createRequest(AmazonS3Client.java:4636)
at com.amazonaws.services.s3.AmazonS3Client.getObject(AmazonS3Client.java:1433)
at com.sompo_swt.integraph.common.S3StorageManager.getS3Object(S3StorageManager.java:58)
<Omission>
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
In the source for accessing S3, the credentials and region were set as follows.
Implementation part for access to S3
S3StorageManager() {
client = AmazonS3ClientBuilder
.standard()
.withRegion(Regions.AP_NORTHEAST_1)
.withCredentials(new AWSStaticCredentialsProvider(getCredentials()))
.build();
}
private AWSCredentials getCredentials() {
return new BasicAWSCredentials(
rb.getString("accessKey")
, rb.getString("secretKey"));
}
Region information is constant, and access key and secret key are written to the property file for management.
I commented out the .withRegion (Regions.AP_NORTHEAST_1)
part as a trial, but it did not disappear. .. ..
It was in a state of being overwhelmed.
When I checked ** NoSuchFieldError: SIGNING_REGION , it seems that this error is It is said that it is caused by " SDK cores of different versions are mixed **".
In this case, the version of ** aws-java-sdk-core ** referenced when executing the corresponding Lambda function via the state machine was different from the version referenced when calling via the CloudWatch event. I thought it was the cause (?).
When I referred to pom.xml, the version of those parts was old as expected, so I matched the version of ** aws-java-sdk-core ** in that part with the latest version in pom.xml, and now I can access S3 safely.
There seems to be a pattern that .withRegion (Regions.AP_NORTHEAST_1)
is bad and occurs, but this time it was because different versions of sdk-core were mixed.
The pom.xml has been modified as follows.
Before correction
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-stepfunctions</artifactId>
<version>1.11.274</version>
</dependency>
Revised
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-stepfunctions</artifactId>
<version>1.11.572</version>
</dependency>
(* Most of them were updated to 1.11.574 when the screenshot was taken, but the modified version 1.11.572 is the latest version at the time of modification)
Regarding this event, the coping method that I took around was a hit, so my understanding remains ambiguous. .. ..
If you have similar problems with Java on Lambda when different versions of SDK are mixed, If you have a better understanding of the details, please comment on why this happens. m (_ _) m
[For super beginners] Maven super introduction Differences between SDK for Java 1.11.x and 2.x
Recommended Posts