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.
Created attachment 153395 [details] init RequestProcessor$TickTac [From email communication with Ron van Grinsven]: The thread in the screenshot below (JboDatabaseCanaryRule) is exclusively constructed to ping the database. It needs its own context classloader, so the JDBC drivers and other db related code can run with the relevant classes available. One of the calls made is shown in the screenshot, which apparently ends up using the RequestProcessor to get a socket connection. This creates a RequestProcessor$TickTac thread, which inherits the context loader from its parent, which is explicitly the URLClassLoader. Subsequently, a RequestProcessor$Processor gets created, which is also getting the context loader from the original thread (so also the URLClassLoader). Now, I'm speculating that the Processor thread is later re-used for other work. I don't know what the pool size is but there seem to be 3 or so of these threads available. Typically, these threads are spawned from other threads that have the ContextFinder. If the indexer process gets assigned to a thread with ContextFinder, then everything works as planned. But if it ends up with the Processor that has the URLClassLoader, then the bug occurs.
Created attachment 153396 [details] init RequestProcessor$Processor
[From email communication with Ron van Grinsven]: I (thurka) discussed the problem with Tomas Pavek (tpavek) and there are several possible solutions. One is to get rid of NBProxySelector - according to Tomas it is not used in JDeveloper. This could be problem due to dependencies in NetBeans code and there could be another cases, where RequestProcessor threads are created from code, which has custom context classloader. Second solution is to avoid RequestProcessor usage from NBProxySelector. This could be easier than first solution, but still there can be other cases, where threads are created with custom context classloader. Third solution is to remember context classloader of calling thread and set it to thread created or reused by RequestProcessor Fourth solution is similar to third one, but context classloader will be some externally defined classloader. If we need to fix it, we think that the third solution is the right one. Hopefully that this solution will not have some unwanted side effects.
Created attachment 153397 [details] Proposed patch Patch to implement proposed (third one) solution.
Fixed in core-main. changeset: 287259:b3691ba57054 user: Tomas Hurka <thurka@netbeans.org> date: Mon Apr 27 13:02:13 2015 +0200 summary: bugfix #252098, remember context classloader of calling thread and set it to thread created or reused by RequestProcessor
Integrated into 'main-silver', will be available in build *201504280001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/b3691ba57054 User: Tomas Hurka <thurka@netbeans.org> Log: bugfix #252098, remember context classloader of calling thread and set it to thread created or reused by RequestProcessor