OOME from PerThreadTagHandlerPool$PerThreadData with many JSPs

Solution Verified - Updated

Environment

  • JBoss Enterprise Application Platform (EAP) 6.x

Issue

  • JBoss throws an OutOfMemoryError with most of the heap consumed by many instances of PerThreadTagHandlerPool$PerThreadData.

Resolution

  • Disable tag-pooling in the web subsystem when you have large JSP and/or thread counts:

      <subsystem xmlns="urn:jboss:domain:web:1.4" default-virtual-server="default-host" native="false">
      <configuration> 
          <jsp-configuration tag-pooling="false"/> 
      </configuration> 
      ...
  </subsystem>

    Note that this can increase JSP compiled size. For large JSPs, they may need to be refactored to disable tag pooling without hitting the 65535 byte limit.

    • That can be set via CLI like so:

        /profile=PROFILE_NAME/subsystem=web/configuration=jsp-configuration:add(tag-pooling=false)

  • Because of the following This content is not included.bug, tmp (which contains compiled jsp objects) may not get cleaned up. So when making this change on a version prior to EAP 6.3.0, you should also delete the JBoss tmp directory between the restart as well. This will ensure old JSP class files previously compiled with the old true tag-pooling setting are discarded so that they will be recompiled with tag-pooling disabled.

Root Cause

  • JBoss's tag pooling will create at most 1 tag pool instance per JSP for each thread (making max pool counts be #ofJSPs * #ofThreads). This potential overhead may be too unreasonable for scenarios with large thread and/or JSP counts.
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.