OQL engine not available

[thurka]

Sometimes OQL is not available and the following exception is thrown in console:
java.lang.ClassNotFoundException: org.netbeans.modules.profiler.oql.engine.api.impl.ReachableExcludes. See attached messages.log for full stack trace.

[thurka]

Steps to reproduce:

1. Start VisualVM
2. on the "Applications" window, double click on "VisualVM"
3. switch to the "Montior" tab
4. click on "Heap Dump"
5. the exception appears on the terminal, OQL is not available

[thurka]

The bug can be always reproduced If you start VisualVM with --nosplash commandline option.

[thurka]

The workaround is to delete splash.png from VisualVM cache directory.

[thurka]

The bug is caused by incorrect context class loader of AWT-EventQueue-0 thread. This incorrect class loader is then used by JavaScript to load ReachableExcludes class in RequestProcessor thread (NB bug #252098). It is expected that all threads in VisualVM have as context class loader instance of (ModuleManager$SystemClassLoader), which can access all the module classloaders at once. Unfortunately ModuleManager$SystemClassLoader class loader is not available at the beginning, so VisualVM starts with the MainImpl$BootClassLoader. Later in the startup sequence when Module system is up, ModuleManager.updateContextClassLoaders will change the context class loader of all running threads to MainImpl$BootClassLoader. Unfortunately this does not always work for AWT-EventQueue-0 thread. This thread is started by java.awt.EventQueue and EventQueue sets context class loader for newly created AWT-EventQueue-0, however this context class loader is remembered by java.awt.EventQueue when it was constructed. AWT-EventQueue-0 thread can be also terminated by java.awt.EventQueue. If AWT-EventQueue-0 is running at the time ModuleManager.updateContextClassLoaders is invoked and if this thread is not terminated by java.awt.EventQueue, everything works fine. However if AWT-EventQueue-0 is terminated by java.awt.EventQueue after ModuleManager.updateContextClassLoaders, the new AWT-EventQueue-0 created by java.awt.EventQueue has MainImpl$BootClassLoader as context class loader instead of correct ModuleManager$SystemClassLoader. In normal VisualVM startup AWT is used very early due to splash screen caching. If VisualVM is started with --nosplash option, AWT is not used during start up and AWT-EventQueue-0 do not run when ModuleManager.updateContextClassLoaders is executed. This this case, AWT-EventQueue-0 is started later when main window is displayed, but again it uses wrong class loader from java.awt.EventQueue. In NetBeans this problem is fixed by using TimableEventQueue, which again sets correct class loader to AWT-EventQueue-0 thread (See TimableEventQueue.initialize(Frame, boolean) method. However VisualVM does not use TimableEventQueue, since it do not log and report problems about too long execution times in its AWT-EventQueue-0 thread.

[thurka]

The problem will be fixed by re-enabling TimableEventQueue in NetBeans platform and disabling TimableEventQueue report functionality via system property org.netbeans.core.TimeableEventQueue.quantum.

[thurka]

Fixed.