This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 184192 - Too many "Active Reference Queue Daemon" threads
Summary: Too many "Active Reference Queue Daemon" threads
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Havlin
Depends on: 245732
Blocks: 86625
  Show dependency tree
Reported: 2010-04-14 16:54 UTC by Jan Lahoda
Modified: 2015-09-07 14:55 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Thread dump. (94.81 KB, text/plain)
2010-04-14 16:54 UTC, Jan Lahoda
thread dump with "Active Reference Queue Daemon" threads (35.55 KB, text/plain)
2015-08-14 15:38 UTC, Tomas Hurka
messages.log (1.06 MB, text/plain)
2015-08-14 15:43 UTC, Tomas Hurka
Quick and ugly fix (2.20 KB, patch)
2015-08-15 11:55 UTC, Tomas Hurka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2010-04-14 16:54:17 UTC
Created attachment 97379 [details]
Thread dump.

See attached thread dump (not a full thread dump, as the top part did not fit into my scrollback). There are 51 util.lookup.implspi.ActiveQueue threads, although there should be only one, AFAIK.
Comment 1 Jaroslav Tulach 2010-04-15 07:51:57 UTC
I did some deadcode cleanup in core-main#15b6f8ac6c4a, but I am not sure how could the ~50 threads be created. Anyway the ping() and related code is provided by Jesse, so passing on.
Comment 2 Antonin Nebuzelsky 2010-10-01 13:39:06 UTC
> related code is provided by Jesse, so passing on.

so reassigning to Jesse
Comment 3 Jesse Glick 2010-10-01 14:07:40 UTC
I see only one such thread in my IDE. Any idea how to reproduce? -J-Dorg.openide.util.lookup.implspi.ActiveQueue.level=0 show anything interesting? I can't find any flaw in the logic from looking at it.
Comment 4 Jesse Glick 2010-10-15 21:11:50 UTC
No more info.
Comment 5 Tomas Hurka 2015-08-14 15:09:45 UTC
Problem is caused by annotation processors, which are loaded by separate classloaders.
Comment 6 Tomas Hurka 2015-08-14 15:14:39 UTC
Steps to reproduce:
1) start IDE with clean userdir and -J-Xmx2G
2) naviage to netbeans repository and open all top-level projects
3) wait for background scanning 
4) take thread-dump
Comment 7 Tomas Hurka 2015-08-14 15:38:57 UTC
Created attachment 155354 [details]
thread dump with "Active Reference Queue Daemon" threads
Comment 8 Tomas Hurka 2015-08-14 15:43:38 UTC
Created attachment 155355 [details]

messages.log showing, who is loading ActiveQueue class.
Comment 9 Tomas Hurka 2015-08-15 11:55:51 UTC
Created attachment 155364 [details]
Quick and ugly fix

Attached is a ugly fix which always loads ActiveQueue via system classloader. It looks like that this patch works fine and there is only one  
"Active Reference Queue Daemon" thread. In addition all instances are garbage-collected after the scanning is done.
Comment 10 Jaroslav Tulach 2015-08-21 05:47:48 UTC
Idea: If the only problem is org.netbeans.modules.openide.filesystems.declmime.MIMEResolverProcessor.generateInstanceResolver, it could tell the Impl not to attach any listeners at all. They are in the same package, so presumably it wouldn't even require an API change.

Re. ugly fix: It's not that ugly. The activeReferenceQueue functionality would behave best if placed directly in the JDK's ReferenceQueue. If we don't have a capacity to make that happen (and I don't), always reusing our global activeReferenceQueue (if available) is the closest we can get.
Comment 11 Jaroslav Tulach 2015-08-21 05:51:04 UTC
Comment 12 Tomas Zezula 2015-08-21 07:44:41 UTC
We tried with Tomas Hurka not to add the listener in MimeResolverImpl, unfortunately the ARQ is started later anyway.
Comment 13 Antonin Nebuzelsky 2015-09-07 14:55:01 UTC
In an offline discussion TomasZ mentioned an option of dividing MIMEResolverImpl into two parts - (1) a model without listening, (2) listening on layers.

However we do not have an easy quick solution for 8.1. Reassigning for future follow-up.