Problems using jdbc-wrapper in Spring Boot native image to connect to RDS via IAM

[rickie]

Describe the bug

To start with some context, we are creating a Spring Boot project with Spring Cloud Functions that uses GraalVM to build a native image and deploy this to AWS Lambda. Here it will connect with API Gateway and has to connect with an RDS instance using IAM authentication.

First of all we noticed that this library doesn't provide reachability metadata for GraalVM out-of-the-box yet, as seen here: https://www.graalvm.org/native-image/libraries-and-frameworks/.
This made us create a few extra config files to ensure the native image works as expected. However, now we have some problems with setting up the AWS advanced JDBC Wrapper to connect to Postgres RDS.

We tried following many different instructions from the docs. For example, this one and this one.

The problem is that we are not able to connect to RDS without any runtime issues. There are problems with packages missing and before connecting that we expect to be provided or done by the jdbc-wrapper. Sometimes we can prevent the problems by being creative and extending our Native image reflection setup. However, there is always a next error. To us, it feels like we are trying to make something work, that perhaps should work out of the box when starting to use this wrapper.

Can you help us identify what is going wrong in our setup and how we can connect to RDS from our Lambda? Your help would be kindly appreciated.

Expected Behavior

We would expect the application to connect to the database.

Right now the logs mention Aurora in the logs as well, why we are not configuring that. Probably there is something going wrong there as well.

What plugins are used? What other connection properties were set?

IAM. And the connection properties user and wrapperPlugins

Current Behavior

We invoke the Lambda via API Gateway to trigger the lambda to start up. Then via CloudWatch we get the logs.

Please see the error logs in this file (from the reproduction case repository).

To summarize the errors we are currently experiencing problems with:

Unable to load connection plugin factory: 'software.amazon.jdbc.plugin.AuroraConnectionTrackerPluginFactory'
....
org.hibernate.exception.GenericJDBCException: unable to obtain isolated JDBC connection [Unable to load connection plugin factory: 'software.amazon.jdbc.plugin.AuroraConnectionTrackerPluginFactory'.] 
...
Caused by: java.sql.SQLException: Unable to load connection plugin factory: 'software.amazon.jdbc.plugin.AuroraConnectionTrackerPluginFactory'

Reproduction Steps

Here is a link to a reproducible case in a repository: https://github.com/ExpressMe/aws-report

Please note that if you actually want to deploy it via the provided CDK files, you'll need to set the environment variables in .env.dev in apps/aws/. The steps to reproduce are listed in the README.

Possible Solution

Additional Information/Context

Some context on why we set things in our project up like this; we want to be able to do two things:

• Deploy a native image to AWS Lambda that can connect with RDS.
• Run the application locally so we can test everything on our PC.

Besides our subproject uppercase we have an even simpler version of a lambda without database things that works like expected when we deploy it to AWS Lambda.

If you have any further questions, please let us know what we can do to help. We would really like to get to the core of the issue such that we can connect to RDS 😄.

The AWS Advanced JDBC Driver version used

2.5.0

JDK version used

21.0.2-graalce

Operating System and version

Linux Ubuntu 22.04

[niek-dewit]

@sergiyvamz @aaron-congo

We investigated this issue a bit further, but this time from a different angle. Instead of building with native image, we tried to connect to the RDS instance via a jar deployment. This worked and you can find it on this branch.

After that, we tried to get the native image setup to work and we made some progress. This takes many cycles because we need to update the reflection-config.json for missing classes. In the commits first commit and second commit you can find our approach. I'm sure we can keep adding missing classes but it feels like we shouldn't be doing this. Can you help us out here? We added our cloudflare log dumps in the referenced commits.

There a few things we changed in the reproducible example:

• Instead of setting values manually in the .env files, now we hardcoded it in the AwsDataSourceConfiguration file.
• Hardcoded the values in the property file spring.datasource.url. While we were trying things, we wanted to make sure everything was configured as simple as possible.
• As we disabled Flyway during the investigation to get to the "core" of the problem. So we manually added a table called users with columns id, name, and email. When running this, make sure to create the table and columns.
• To be able to run the application, we created a TODO.sql file, that contains some statements that need to be executed.

We hope that having this working case without native image makes it easier to troubleshoot the issue. It would be awesome if we can figure out the issue and run the setup with Native Image :D.

[davecramer]

We can probably add reachability data.

[aaron-congo]

Hi @niek-dewit and @rickie,

Thanks for reaching out and raising this issue. We'll take a look at this and keep you updated as we investigate.

[aaron-congo]

Just an update, I was unfamiliar with native image and reachability metadata, but I've been spending time this week familiarizing myself and am currently in the process of creating/testing our reachability metadata. We use a fair bit of reflection so there's a number of cases to test. I'll continue working on this next week.