Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-6626

ThreadlocalPool.discard() memory leak when exception thrown from bean method

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Obsolete
    • 4.3.0.GA_CP09
    • TBD EAP 4
    • EJB
    • None
    • Release Notes
    • Workaround Exists
    • Hide

      Use StrictMaxPool instead

      Show
      Use StrictMaxPool instead
    • Hide
      Whenever a stateless session bean throws an exception, the instance is supposed to be discarded from memory. There is however a known issue in the InfinitePool which retains the instance regardless. Because the instances are retained, the server will at some point run out of memory if enough exception conditions have occurred. A ThreadlocalPool is backed by an InfinitePool, so it also is affected. There are two workarounds available:
      <orderedlist>
      <listitem><para>Periodically restart the server</para></listitem>
      <listitem><para>Use StrictMaxPool</para></listitem>
      </orderedlist>

      Workaround 1 introduces a downtime period.
      Workaround 2 introduces latency as the StrictMaxPool has a choke point for controlling the maxSize restriction. Additionally, the number of instances available might not be enough to service the load.
      Show
      Whenever a stateless session bean throws an exception, the instance is supposed to be discarded from memory. There is however a known issue in the InfinitePool which retains the instance regardless. Because the instances are retained, the server will at some point run out of memory if enough exception conditions have occurred. A ThreadlocalPool is backed by an InfinitePool, so it also is affected. There are two workarounds available: <orderedlist> <listitem><para>Periodically restart the server</para></listitem> <listitem><para>Use StrictMaxPool</para></listitem> </orderedlist> Workaround 1 introduces a downtime period. Workaround 2 introduces latency as the StrictMaxPool has a choke point for controlling the maxSize restriction. Additionally, the number of instances available might not be enough to service the load.
    • Documented as Known Issue
    • NEW

    Description

      Platform JIRA for EJBTHREE-2251

      Attachments

        Activity

          People

            rhn-engineering-cdewolf Carlo de Wolf
            rhn-support-tkimura Takayoshi Kimura
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: