[Bug# 228886] Multiple Glassfish threads hanging in memory

Tomas Kraus <[email protected]> Tue, 21 May 2013 13:42:44 +0200
Newsgroups gmane.comp.java.netbeans.reviewers
Message-ID <[email protected]> 
This is a multi-part message in MIME format.
--------------050406050409090101020005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

*Bug 228886* <https://netbeans.org/bugzilla/show_bug.cgi?id=228886> 
-Multiple Glassfish threads hanging in memory

Zombie thread is left after GlassFish Log Reader thread has been 
interrupted in build task.

- Start NetBeans
- Start VisualVM and open NetBeans, threads table, sort by Thread
- Create sample project ServletStateless
- Start GlassFish server in debug mode
- Undeploy all projects
Repeat the following cycle
- Run project ServletStateless
   creates one thread FetchLogPiped
- Clean and build project
   creates one thread FetchLogPiped.

So if you run this cyle 3 times you should have 6 FetchLogPiped threads.

Fix in GF plugin was made in 4 steps (253015:70350e3b09dc, 
253069:422df5694675, 253094:1ad1e811d955 and 253176:e0be6fab29ed), 
combined diff is attached as 
https://netbeans.org/bugzilla/attachment.cgi?id=134564&action=diff

I made single thread pool (ExecutorService) to be shared for all 
GlassFish Log Reader threads. Threads are run under top level 
ThreadGroup to not be interrupted by build task. Threads have 
setDaemon(true) set to avoid them being NB exit blockers.

GlassFish Tooling Library changeset is 502:280234be9cb0.

It allows to pass external ExecutorService into GlassFish Log Reader 
thread starting code.

Code went trough 2 reviews - Petr Hejl and Peter Benedikovic. It was 
cleaned up thanks to Petr Hejl notes and now I believe it's safe enough 
to be pushed in to 7.3.1 release branch. QA testing was done by Jiri 
Skrivanek. More details are in the bug.


--------------050406050409090101020005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <a href="https://netbeans.org/bugzilla/show_bug.cgi?id=228886"><b>Bug&nbsp;228886</b></a>
    -<span id="summary_alias_container"> <span
        id="short_desc_nonedit_display">Multiple Glassfish threads
        hanging in memory<br>
        <br>
        Zombie thread is left after GlassFish Log Reader thread has been
        interrupted in build task.<br>
      </span></span>
    <pre class="bz_comment_text">- Start NetBeans
- Start VisualVM and open NetBeans, threads table, sort by Thread
- Create sample project ServletStateless
- Start GlassFish server in debug mode
- Undeploy all projects
Repeat the following cycle
- Run project ServletStateless
  creates one thread FetchLogPiped
- Clean and build project
  creates one thread FetchLogPiped.

So if you run this cyle 3 times you should have 6 FetchLogPiped threads.</pre>
    Fix in GF plugin was made in 4 steps (253015:70350e3b09dc,
    253069:422df5694675, 253094:1ad1e811d955
    and 253176:e0be6fab29ed), combined diff is attached as
    <a class="moz-txt-link-freetext" href="https://netbeans.org/bugzilla/attachment.cgi?id=134564&amp;action=diff">https://netbeans.org/bugzilla/attachment.cgi?id=134564&amp;action=diff</a><br>
    <br>
    I made single thread pool (ExecutorService) to be shared for all <span
      id="summary_alias_container"><span id="short_desc_nonedit_display">GlassFish
        Log Reader </span></span>threads. Threads are run under top
    level ThreadGroup to not be interrupted by build task. Threads have
    setDaemon(true) set to avoid them being NB exit blockers.<br>
    <br>
    GlassFish Tooling Library changeset is 502:280234be9cb0.<br>
    <br>
    It allows to pass external ExecutorService into <span
      id="summary_alias_container"><span id="short_desc_nonedit_display">GlassFish
        Log Reader </span></span>thread starting code.<br>
    <br>
    Code went trough 2 reviews - Petr Hejl and Peter Benedikovic. It was
    cleaned up thanks to Petr Hejl notes and now I believe it's safe
    enough to be pushed in to 7.3.1 release branch. QA testing was done
    by Jiri Skrivanek. More details are in the bug.<br>
    <br>
  </body>
</html>

--------------050406050409090101020005--