Memory leak in Java SDK?

Yes, there are known memory leak issues with the AWS Java SDK. Specifically, there have been reports of memory leaks with the Java SDK V2, as documented in GitHub issues. While the reported issues are for V2, it's possible similar issues could affect V1 as well.

The symptoms you're describing - a slow but steady increase in memory usage (100k per minute) that eventually leads to an out-of-memory error after weeks of running - are consistent with a memory leak. Your observation that the leaked memory appears to be held in byte arrays within the "netty" package aligns with this possibility.

To diagnose and address this issue, you could:

1. Monitor your heap usage over time. If the used space continuously grows until it reaches total capacity, that's a strong indication of a memory leak.

2. Try upgrading or downgrading your SDK version to see if a different version resolves the issue.

3. Consider implementing more aggressive resource management, such as:

• Ensuring all closeable resources are properly closed
• Periodically restarting components that might be leaking (as you've already tried with SQS)
• Implementing a scheduled restart of your application before memory issues become critical

4. If the issue persists, you might need to collect more detailed diagnostics:

• Enable debug logging
• Capture heap dumps at different points in time
• Run a TCP dump for affected connections to identify any network-related issues

If you continue to experience problems, consider reaching out to AWS Support with detailed information about your implementation, including request IDs and timestamps of when the issue occurs.
Sources
Is there known memory leak issues with aws-java-sdk-bundle-1.11.837.jar ? | AWS re:Post
Understanding the heap summary - Amazon CodeGuru Profiler

Yes, Memory leak issues in the AWS Java SDK, particularly when using Netty-based asynchronous clients in long-running processes like yours. You're not imagining it, and your detective work with Eclipse Memory Analyzer is spot-on.

Netty ByteBuf leaks: Netty uses off-heap memory via ByteBuf, which must be manually released. If release() isn’t called properly, memory accumulates and GC won’t help. AWS SDK V2 async clients (like SqsAsyncClient) use Netty under the hood. If you're using these without proper resource cleanup, leaks can occur. Long-lived connections (like your SQS/IOT clients) can retain buffers or threads if not shut down correctly. What You Can Do**

1. Enable Leak Detection Add this JVM flag to catch leaks early: -Dio.netty.leakDetection.level=ADVANCED This will log warnings like: LEAK: ByteBuf.release() was not called before it's garbage-collected.

2. Use Shared Clients

Avoid creating new SDK clients per request. Instead: Create a singleton client and reuse it. Shut it down gracefully when no longer needed: sqsClient.close();

3. Upgrade SDK Version Use the latest AWS SDK V2 (e.g., 2.20.x or newer). Several memory-related fixes have been applied over time. Especially avoid older versions like 2.5.x or 2.7.x, which had confirmed leaks in Netty integration.

4. Limit Netty Buffer Pooling

Try disabling Netty’s buffer recycler: -Dio.netty.recycler.maxCapacity=0 Or limit direct buffer cache: Bash: -Djdk.nio.maxCachedBufferSize=262144

5. Monitor Off-Heap Memory Use tools like:

• Amazon CodeGuru Profiler for JVM memory profiling
• VisualVM or YourKit to inspect direct memory usage

Thanks, I'm currently using a singleton. The purpose of the connection is to receive rather than send, so it must remain open continuously, therefore calling close is irrelevant in this case. I do call close, but only when my entire application is being unloaded, which means only when I'm deploying a new version of the software (not often).

I'm using version 2.31.78 of the AWS SDK. I'll try getting rid of the recycler buffer.