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.
In order to move to simpler module assembly and deployment in our web applications, I decided to give the META-INF/services a try. That would allow us to deploy different implementations (jars) to different customers, each having the implementation that fits them best. Originally I used the JDK ServiceLoader, but that API is rather limited, for example lacking notification of changes. So I switched to the Lookup API, although I know it was designed for desktop applications, not for long-running server software. This change immediately caused a memory leak when the webapp was unloaded. Within a few reloads we got a PermGen OutOfMemory exception. That turned out to be a Timer thread that could never be cancel()-ed. We were still using an older version of the lookup library, so I switched to the new one, from NetBeans 7, platform/lib/org-openide-util-lookup.jar and org-openide-util.jar. Unfortunately, the RequestProcessor class from org-openide-util.jar still suffers from the same problem. It turned out this is caused by my LookupListener. Adding a LookupListener caused several threads to start (and never end). One thread is a Timer thread (Timer-0, Timer-1 etc), another one is called "Active Reference Queue Daemon". As long as I avoid the event notification functionality of Lookup, everything is working fine. Is there anything I can do to end those threads?
Created attachment 114634 [details] Two tests showing the problem and a brute-force fix of one of them
ergonomics#65559f0f82fd
Created attachment 114656 [details] org-openide-util-lookup.jar with the fix
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/65559f0f82fd User: Jaroslav Tulach <jtulach@netbeans.org> Log: #206621: Worker threads in ActiveQueue and RequestProcessor are able to cancel itself, when these subsystems are no longer needed.
*** Bug 232437 has been marked as a duplicate of this bug. ***