[
https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224553#comment-16224553
]
Jaroslav Tulach commented on NETBEANS-106:
------------------------------------------
1. I've managed to simulate the deadlock.
2. There is the {{Future}} equilibristic - why? Wouldn't this be simpler?
{code}
$ hg exp 1
# HG changeset patch
# User Jaroslav Tulach <[email protected]>
# Date 1509355368 -3600
# Mon Oct 30 10:22:48 2017 +0100
# Node ID 48c22a5fe2c42e84c02431b61648f87bf7186599
# Parent c5475ded461f5e7cce361dbbb760e3fc2e7fb212
Simpler way to run on code when UI is ready
diff -r c5475ded461f -r 48c22a5fe2c4
src/nb/auth/deadlock/NetworkTaskStarter.java
--- a/src/nb/auth/deadlock/NetworkTaskStarter.java Mon Oct 30 10:10:40
2017 +0100
+++ b/src/nb/auth/deadlock/NetworkTaskStarter.java Mon Oct 30 10:22:48
2017 +0100
@@ -13,6 +13,7 @@
import org.openide.modules.OnStart;
import org.openide.util.Exceptions;
import org.openide.util.RequestProcessor;
+import org.openide.windows.OnShowing;
import org.openide.windows.WindowManager;
@@ -47,30 +48,22 @@
@Override
public void run() {
+ WindowManager.getDefault().invokeWhenUIReady(new Runnable() {
+ @Override
+ public void run() {
+ whenShowing();
+ }
+ });
+ }
+ final void whenShowing() {
rp.post(new Runnable() {
@Override
public void run() {
- try {
- // Lots of cerimony to wait for UI to be ready
- FutureTask<Void> uiInit = new FutureTask<>(new
Callable<Void>() {
- @Override
- public Void call() throws Exception {
- return null;
- }
- });
- WindowManager.getDefault().invokeWhenUIReady(uiInit);
- uiInit.get();
-
- // Install our own Authenticator
- Authenticator.setDefault(new CustomAuthenticator());
-
- // Fire our simulated network task
- rp.post(new NetworkTaskSimulator());
-
- } catch (InterruptedException | ExecutionException ex) {
- Exceptions.printStackTrace(ex);
- }
+ // Install our own Authenticator
+ Authenticator.setDefault(new CustomAuthenticator());
+ // Fire our simulated network task
+ rp.post(new NetworkTaskSimulator());
}
});
}
{code}
3. Even simpler it is to use {{@OnShowing}} annotation. It deadlocks as well
(yet without showing the main window):
{code}
authnbdead$ hg diff
diff -r 7f59a7578504 src/nb/auth/deadlock/NetworkTaskStarter.java
--- a/src/nb/auth/deadlock/NetworkTaskStarter.java Mon Oct 30 10:23:00
2017 +0100
+++ b/src/nb/auth/deadlock/NetworkTaskStarter.java Mon Oct 30 10:26:36
2017 +0100
@@ -30,7 +30,7 @@
*
* @author lbruun
*/
-@OnStart
+@OnShowing
public class NetworkTaskStarter implements Runnable {
private static URL TEST_URL;
@@ -48,15 +48,6 @@
@Override
public void run() {
- WindowManager.getDefault().invokeWhenUIReady(new Runnable() {
- @Override
- public void run() {
- whenShowing();
- }
- });
- }
-
- final void whenShowing() {
rp.post(new Runnable() {
@Override
public void run() {
{code}
> NB classloaders should use fine grained locking
> -----------------------------------------------
>
> Key: NETBEANS-106
> URL: https://issues.apache.org/jira/browse/NETBEANS-106
> Project: NetBeans
> Issue Type: Bug
> Reporter: lbruun
>
> In order to avoid issues such as NETBEANS-58 the NB classloaders should use
> fine grained locking. (possibly only needed on System Classloader)
> Background: At the time when the NB classloaders were created the general
> consensus at the time was that a proper classloader used locking at the level
> of the classloader itself. This was also how the classloaders in the JDK
> worked. However, in Java 7 this
> [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html].
> The JDK classloaders started using more fine grained locking. But the NB
> classloaders didn't follow suit. (it is not exactly an inheritable feature)
> This means we are now in a situation were deadlocks occur in NB code which
> cannot be reproduced with only the JDK. One such case is JDK-8068184 which
> causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix
> problems that occur only in NB code.
> What I propose is that a more fine grained locking mechanism is used. Look to
> the JDK for inspiration. This will solve such deadlock issues. I don't think
> it is necessary to actually claim that it is now fully multi-thread safe by
> calling
> [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()].
> This can be left for a later exercise. First step is to remove the lock on
> the classloader as a whole.
> NETBEANS-58 contains a simple [minimal
> example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149]
> which can be used as a measure of success. Once an NB application can use
> the pattern in the example without freezing then we have accomplished the
> goal.
>
> (I'm personally not confident with fiddling with the NB classloaders. Scares
> the sh.. out of me because I know it is the heart of the platform. So won't
> come up with a PR. Sorry.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
