Re: [Bug# 228886] Multiple Glassfish threads hanging in memory
Jiri Skrivanek <[email protected]> Wed, 22 May 2013 15:41:27 +0200
| Newsgroups | gmane.comp.java.netbeans.reviewers |
|---|---|
| Organization | Oracle Corporation |
| Message-ID | <[email protected]> |
I tried attached jars in NB7.3.1 and there exists only one FetchLogPiped thread within live threads at the time. I haven't noticed any regression so far. Jiri On 22.5.2013 14:53, Tomas Kraus wrote: > OK, here are simple changes. I tested it using > https://netbeans.org/bugzilla/show_bug.cgi?id=228886#c12 and looks like > there are no old threads left. > > Jiri, please test it too to be sure. JARs were built using clean > release73 branch. > > Tomas > > On 05/22/2013 11:53 AM, Petr Jiricka wrote: >> On May 22, 2013, at 11:32 AM, Tomas Kraus wrote: >> >>> The fix Petr H suggested yesterday is simple - change minimal pool >>> size in tooling library to 0. I would also add shutdown call to close >>> method. It's 2 lines change but it solves only part of the issue - >>> hanging threads in memory. >> The question is whether it fixes the *main* issue. We are in high >> resistance mode, so only serious and severe issues should be fixed, >> not P3-grade issues - especially at the risk of introducing regressions. >> >>> Log readers will still be interrupted in build task. >>> >>> But it's up to you. I'll do one more release branch clone to prepare >>> this version. >> If the simple fix fixes the main issue, and everyone agrees that this >> change is correct and safe, then let's do it this way. >> >> Thanks, >> Petr >> >> >>> Tooling Library changes don't have to be removed because new code >>> won't be used. >>> >>> Tomas >>> >>> On 05/22/2013 11:25 AM, Petr Jiricka wrote: >>>> On May 21, 2013, at 9:58 PM, Petr Hejl wrote: >>>> >>>>> Hi, >>>>> I'm sorry, but your formulation looks like I'm ok with the patch. >>>>> >>>>> What I don't like about the patch? It is a bit large and does fixes >>>>> in area which is hard and error prone on its own (threading). It >>>>> also fixes a lot more than just thread leak, while there is simpler >>>>> solution to the leak itself. We already found one issue in the >>>>> original patch and looking at the diff there is another one in the >>>>> library - not synchronized access to eventListeners in >>>>> notifyListeners. >>>> In the light of this, it is clear that this fix is too risky - let's >>>> not put it into 7.3.1. >>>> >>>> Tomas, is there a simpler fix that would fix the main problem and >>>> that would be non-controversial? I believe Petr H suggested an >>>> uncomplicated fix, could we use that? If we do, then we should give >>>> QA a jar file with the fix for testing with 7.3.1 builds. >>>> >>>> Thanks, >>>> Petr >>>> >>>> >>>>> So the whole thing is a little bit risky from my point of view. >>>>> >>>>> I have no objections about the integration if other reviewers are >>>>> happy about the patch. >>>>> P. >>>>> >>>>> On 05/21/2013 01:42 PM, Tomas Kraus wrote: >>>>>> *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. >>>>>> >