Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Elastic Beanstalk Tomcat 10/11 injects invalid JVM flags (-XX:MaxPermSize, empty -Xmx/-Xms) on Java 17+

0

We are encountering a platform-level JVM startup failure when using Elastic Beanstalk Tomcat 10/11 with Java 17+ (Amazon Corretto).
This occurs before any application code executes and is reproducible even with a minimal WAR.

Environment

  • Service: Elastic Beanstalk
  • Platform: Tomcat 10 (also reproducible on Tomcat 11)
  • Operating System: Amazon Linux 2023
  • Java: Amazon Corretto 17 / 21
  • Application type: WAR
  • Framework: Spring Framework 6 (Jakarta)

Note: This deployment is WAR-based by requirement, so switching to the Java SE platform or an executable JAR is not an option.

Observed behavior

During Tomcat startup, Elastic Beanstalk injects legacy and invalid JVM flags into the JVM command line: -XX:MaxPermSize=256m -Xmx -Xms

This causes the JVM to exit immediately: Unrecognized VM option 'MaxPermSize=256m' Invalid maximum heap size: -Xmx Error: Could not create the Java Virtual Machine.

As a result, Tomcat never binds to port 8080.

This failure happens before any Spring or application logic is executed.

Troubleshooting already performed

  • .ebextensions JVM options

    • These are append-only and cannot remove injected flags

  • .platform/hooks/prebuild to override /etc/sysconfig/tomcat10

    • Hook executes successfully (confirmed in /var/log/eb-engine.log)
    • EB still injects JVM flags later during Tomcat startup

  • Cleared Min/Max heap settings in the EB Console

    • EB still injects empty -Xmx / -Xms

  • Explicitly setting Min/Max heap settings in the EB Console

    • EB injects proper -Xmx / -Xms along with -XX:MaxPermSize=256m hence it still results in error

  • Explicitly set Java version (Corretto 17 and 21)

    • No change in behavior

Why this appears to be a platform issue

  • -XX:MaxPermSize has been invalid since Java 8
  • Java 17+ correctly fails hard on this option
  • Elastic Beanstalk Tomcat platform still injects it unconditionally
  • Empty -Xmx / -Xms are injected even when memory settings are unset
  • This makes Tomcat 10/11 effectively unusable on Java 17+ for WAR deployments

Expected behavior

  • Elastic Beanstalk Tomcat 10/11 should not inject -XX:MaxPermSize on Java 17+
  • Elastic Beanstalk should not inject empty -Xmx / -Xms
  • Or provide a supported way to disable EB-managed JVM memory flags

Questions

  1. Is this a known limitation or bug in the Elastic Beanstalk Tomcat 10/11 platform?
  2. Is there a supported workaround for WAR-based deployments (without switching to Java SE or Docker)?
  3. Is Tomcat 10/11 officially supported on Java 17+ in Elastic Beanstalk?

Any guidance or confirmation would be appreciated.

Topics
ComputeDeveloper ToolsJava Development
Tags
Amazon Linux 2023Amazon CorrettoJava DevelopmentAWS Elastic Beanstalk
Language
English

asked 10 months ago198 views

1 Answer
0

This is indeed a known issue with AWS Elastic Beanstalk's Tomcat platform when using Java 17 or later. The problem stems from JDK 17 removing support for the -XX:MaxPermSize option, which was previously used to configure the PermGen space in older Java versions.

On July 13, 2023, AWS Elastic Beanstalk released a new Tomcat platform branch based on Amazon Linux 2023 (AL2023) that includes Corretto 17 with Tomcat 10. The documentation explicitly mentions that JDK 17 removed support for the Java -XX:MaxPermSize option, and using this option with this platform branch will result in an error.

Regarding your specific questions:

  1. Yes, this is a known limitation documented by AWS. The -XX:MaxPermSize option is incompatible with JDK 17 and later.

  2. For a supported workaround, you should check the JVM Container options in the Elastic Beanstalk Developer Guide. While the documentation doesn't provide a specific solution for removing these flags, you might need to:

  • Configure your environment without using the built-in JVM memory management
  • Use custom platform hooks to modify the startup configuration after Elastic Beanstalk has applied its settings
  • Consider creating a custom platform version if the above options don't work
  1. Yes, Tomcat 10 is officially supported on Java 17+ in Elastic Beanstalk. The Corretto 17 with Tomcat 10 AL2023 platform version 5.0.0 was specifically designed for this combination. However, there appear to be configuration issues with the default JVM options that need to be addressed.

The empty -Xmx and -Xms flags you're experiencing might be related to how the platform handles unset or improperly configured memory settings. When you explicitly set these values in the EB Console, they should have proper values, but the -XX:MaxPermSize flag will still cause issues with Java 17+.

I recommend reaching out to AWS Support for a definitive solution to this platform-level issue, as it appears to be a fundamental configuration problem with how the Tomcat platform injects JVM flags for Java 17+ environments.
Sources
Release: Elastic Beanstalk launches Amazon Linux 2023 Tomcat platform on July 13, 2023 - AWS Elastic Beanstalk
Using the Elastic Beanstalk Tomcat platform - AWS Elastic Beanstalk

answered 10 months ago

  • Prabu
    10 months ago

    Thank you for the confirmation.

    To clarify: based on your response, it appears that while Tomcat 10 on Java 17+ is officially supported on Elastic Beanstalk, the platform currently injects JVM flags (-XX:MaxPermSize) that are incompatible with Java 17+, and there is no supported way to disable or override this behavior for WAR-based deployments.

    Can you please confirm:

    1. Whether there is a planned fix or timeline for correcting the default JVM options on the Tomcat 10/11 AL2023 platforms, or
    2. Whether WAR-based deployments on Tomcat 10/11 + Java 17+ are currently considered unsupported in practice.

    This confirmation would help us make an architectural decision.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content