Bug 127367

Created attachment 56662 [details]
stacktrace

reassigning to db for evaluation

Sorry, with the latest bits, I can't reproduce.

Looking at the stack trace, it's hard to understand how it could happen unless there is a threading bug, as
DatabaseNodeInfo calls add with a new node array instantiated with a node that it checked to see was not null.  But when
Children.java hits it, the node is null.

I am suspecting this is related to your other issues with managing connections which have appeared to have gone away
with the latest bits.  I will close with WORKSFORME, and please re-open if you see it again.

Fixed. 

Fixed.

Verified with build 080218.

I am hitting this issue again in build 770 from deadlock. For me, the steps to reproduce are:
1. Create a new web project
2. From the first panel of the wizard, choose Add server (I used the zip build so there are no servers to start with)
3. Add GlassFish v2 using the Add Server wizard
4. On finishing the wizard and returning back to the new web project wizard, I got the exception, see new stack trace in
the attachment.

Created attachment 57562 [details]
Updated stack trace

Build: NetBeans IDE Dev (Build 200803011643)
VM: Java HotSpot(TM) Client VM, 10.0-b19
OS: Windows XP, 5.1, x86

User Comments: 
selected Services tab

Created attachment 57613 [details]
stacktrace

Build: NetBeans IDE Dev (Build 200803021202)
VM: Java HotSpot(TM) Client VM, 10.0-b19
OS: Linux, 2.6.12-10-686, i386

User Comments: 
Downloaded Java SE distro and run with new userdir

Created attachment 57622 [details]
stacktrace

Exception on startup - download Java SE distro and run it against new userdir -> NPE rises

Just discovered this bug after being offline over the weekend.  Will get it fixed ASAP.

I am noticing that these issues seem to arise when using J2EE/Visualweb functionality.  So I am suspicious that I am not
seeing this because I am running with the 'basic' configuration.   Building with the 'standard' cluster configuration
and will see if I can reproduce.

Meanwhile while the build's going on I'll look at the code and see if I can determine the cause through inspection.

Unable to reproduce on startup with clean userdir and a fresh build from main.  Am downloading Glassfish V2 to see if I
can reproduce that way.

mmirolivic, can you please give me the following information:
- which build are you using - standard build, basic build, full build or something else?
- which VM are you using?  I can't tell if "Java HotSpot(TM) Client VM, 10.0-b19" which VM this is - Java 5 or Java 6

Thanks.

Further inspection of the stack trace is uncovering the cause to me - it happens when registering Java DB that is
discovered in JDK 6 or when Glassfish is registered.

I'll install JDK 6 and see if I can reproduce that way.

Further inspection of the stack trace is uncovering the cause to me - it happens when registering Java DB that is
discovered in JDK 6 or when Glassfish is registered.

I'll install JDK 6 and see if I can reproduce that way.

Reproduced (yay!).  I reproduce by manually registering Java DB.  Now I can work on tracking down the cause.

David,
> mmirolivic, can you please give me the following information:
> - which build are you using - standard build, basic build, full build or something else?

as you can see in my original report, I am using Java SE distribution

> - which VM are you using?  I can't tell if "Java HotSpot(TM) Client VM, 10.0-b19" which VM this is - Java 5 or Java 6
jdk 1.6.0_04

Update: this is a Heisenbug.  Due to a threading conflict that I have yet to unravel, the Java DB node gets added twice,
and this causes subsequent corruptions in the node hierarchy that results in the NPE.

Stepping through in the debugger and/or adding log statements that print out stack traces to track down what threads are
participating in the problem makes the behavior go away.

Now attempting to track down without the use of log statements or the debugger.  Are we having fun yet?

Placed synchronization in a number of places where it was missing, and now it is working for me in my sandbox.  I will
work on getting this integrated into the trunk.

Fixed in main http://hg.netbeans.org/main?cmd=changeset;node=5490ae2f3361

Need to merge into beta1 repository after verification.

Jan Horvath is verifying...

verified in main. please integrate into beta1 repository.

Merged into beta branch

http://hg.netbeans.org/release61-beta?cmd=changeset;node=889b9cf9fe5b

I can't argue about the correctness of the changes because the threading model of DatabaseNodeChildren was already
incomprehensible. To quote a comment at the end of the file, which is about five years old, "this entire class is junk".
It should have been thrown away a long time ago, and it is quite dissapointing that someone still has to struggle
maintaining it.

That being said, David's changes do seem to improve the current state, so I agree with them. Unfortunately, I don't
think they are the correct fix, which would be to "have a sensible data model independent of nodes and display it using
Children.Keys [...] and everything would be much easier" (to quote from the class again). However, that fix would
require heavy changes to the DB Explorer, changes that have always been unpopular. Again, it is quite demotivating (to
me at least) to see how we focus on better database support without addressing the infrastructure issues first.

A nitpick (not intended to block the integration into the beta branch): synchronization is not needed on getProperty()
and getBooleanProperty() in MySQLOptions. Similarly, it is not needed on ServerNodeProvider.getNodes().

Just few hints (probably not necessary for beta).

- Is there real need for usage of three different loggers in single class (DatabaseNodeChildren.java)?
- No need to synchronize static MySQLOptions.getDefault()
- MySQLOptions listeners are not thread safe, use CopyOnWriteArrayList
- Some unit test case should be prepared to avoid future regressions
- It is always good idea to document which lock is used for the field being synchronized

Thanks for your comments, your suggested changes are very useful; I have made the changes and will push into main (not
beta branch).

Petr, regarding your comment on unit tests, I am well aware of this.  I had to set this aside as I had features that I
wanted to get in for beta.  Unit tests are my main task for the beta period (aside from fixing P1s/P2s).

David

I haven't seen that exception any more - verified.

Some small changes based on review comments

http://hg.netbeans.org/main?cmd=changeset;node=c5af08a950f9