ActiveMQ
  1. ActiveMQ
  2. AMQ-1214

threads not stopping causing memory leaks which can lead to OutOfMemoryError

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.0
    • Fix Version/s: 5.2.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      Fedora Core 6

      Description

      Threads started by ActiveMQ on behalf of a client persist in a ThreadGroup despite calling the 'interrupt' method on the group thereby leaking memory.

      1. test.java
        4 kB
        Anish Pathadan
      2. ASF.LICENSE.NOT.GRANTED--threadleak.tar.gz
        1 kB
        Ted X Toth

        Activity

        Hide
        Anish Pathadan added a comment -

        Hi All,
        This bug can be closed as the threads persisted are valid.

        If we run the original test case(ie threadleaker.tar.gz), we can see the threads which persisted are two "ActiveMQ Scheduler" threads. These threads are executed using ScheduledThreadPoolExecutor with a pool size of 5. Pool size of 5 means a maximum of 5 such threads will be available in the pool and these threads will be used to execute n number of "ActiveMQ Scheduler" threads.

        If connection is created and closed a lot of times, a maximum of 5 "ActiveMQ Scheduler" threads and lots of "ActiveMQ Connection worker" threads will be created.The latter thread is created to be timed out after 5 seconds of creation.

        This can be verified by executing the attached test.java . This testcase prints the total number of threads in the system after a connection.start() and connection.close() is called.The total number of threads never increases to a very high number as the initial threads are getting timed out.

        Thanks,
        Anish

        Show
        Anish Pathadan added a comment - Hi All, This bug can be closed as the threads persisted are valid. If we run the original test case(ie threadleaker.tar.gz), we can see the threads which persisted are two "ActiveMQ Scheduler" threads. These threads are executed using ScheduledThreadPoolExecutor with a pool size of 5. Pool size of 5 means a maximum of 5 such threads will be available in the pool and these threads will be used to execute n number of "ActiveMQ Scheduler" threads. If connection is created and closed a lot of times, a maximum of 5 "ActiveMQ Scheduler" threads and lots of "ActiveMQ Connection worker" threads will be created.The latter thread is created to be timed out after 5 seconds of creation. This can be verified by executing the attached test.java . This testcase prints the total number of threads in the system after a connection.start() and connection.close() is called.The total number of threads never increases to a very high number as the initial threads are getting timed out. Thanks, Anish
        Hide
        james strachan added a comment -

        Thanks for the heads up Anish!

        Show
        james strachan added a comment - Thanks for the heads up Anish!
        Hide
        Stefan Reuter added a comment -

        I have two problems with this issue:
        1. You shouldn't set the resolution to "fixed" when you didn't fix anything
        2. "threads persisted are valid" - this depends on what you consider valid.

        When deployed to a web container like Tomcat the threads are not shut down and cause a PermGen leak. The fix would be quite easy: Just shut it down in some destroy method or at least make it clear to user's that they have to take care of the clean up.

        More information:

        http://www.mail-archive.com/activemq-users@geronimo.apache.org/msg05687.htmlvv
        http://www.mail-archive.com/activemq-users@geronimo.apache.org/msg05706.html

        http://blogs.reucon.com/srt/2007/07/20/java_lang_outofmemoryerror_permgen_space.html

        Show
        Stefan Reuter added a comment - I have two problems with this issue: 1. You shouldn't set the resolution to "fixed" when you didn't fix anything 2. "threads persisted are valid" - this depends on what you consider valid. When deployed to a web container like Tomcat the threads are not shut down and cause a PermGen leak. The fix would be quite easy: Just shut it down in some destroy method or at least make it clear to user's that they have to take care of the clean up. More information: http://www.mail-archive.com/activemq-users@geronimo.apache.org/msg05687.htmlvv http://www.mail-archive.com/activemq-users@geronimo.apache.org/msg05706.html http://blogs.reucon.com/srt/2007/07/20/java_lang_outofmemoryerror_permgen_space.html
        Hide
        Rob Davies added a comment -

        Fix applied in SVN revision 669512

        Show
        Rob Davies added a comment - Fix applied in SVN revision 669512

          People

          • Assignee:
            Rob Davies
            Reporter:
            Ted X Toth
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development