Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 189679 - Freeze during project opening
Freeze during project opening
Product: webservices
Classification: Unclassified
Component: JAX-WS
: P2 (vote)
: 7.0
Assigned To: Milan Kuchtiak
Depends on:
  Show dependency treegraph
Reported: 2010-08-19 11:24 UTC by Tomas Danek
Modified: 2010-08-21 03:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT

thread dump (23.97 KB, text/rtf)
2010-08-19 11:24 UTC, Tomas Danek
The same, in plain text format (23.29 KB, text/plain)
2010-08-19 13:22 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Danek 2010-08-19 11:24:40 UTC
Created attachment 101524 [details]
thread dump

Product Version: NetBeans IDE Dev (Build maven-dev-203-on-100813)
Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01-279
System: Mac OS X version 10.6.4 running on x86_64; MacRoman; en_US (nb)
Userdir: /Users/tomas/.netbeans/dev
thread dump attached
Comment 1 Jesse Glick 2010-08-19 13:22:26 UTC
Created attachment 101528 [details]
The same, in plain text format

Please do not use strange formats when plain text would suffice.
Comment 2 Jesse Glick 2010-08-19 13:39:33 UTC
The IDE was turning on Maven support modules, so may be specific to FoD, but not necessarily.

Is there any way to reproduce this problem? Is there any reason to believe it is specific to the maven-dev branch (I don't see any reason based on the thread dump)?

Are you intentionally running the Server VM?

The EQ thread is not blocked but looks busy. Was the CPU still running or not? The activity looks to be in JAX-WS, not Maven per se:

"Lookup Dispatch Thread" daemon prio=1 tid=152087000 nid=0x139626000 in Object.wait() [139624000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(
	at org.netbeans.modules.websvc.jaxws.light.JAXWSLightSupportAccessor.<clinit>(
"FoD Processor" daemon prio=1 tid=102c44000 nid=0x14f8a2000 in Object.wait() [14f89e000]
   java.lang.Thread.State: RUNNABLE
	at org.netbeans.modules.websvc.jaxws.light.api.JAXWSLightSupport.<clinit>(

My suspicion is that this variant of the accessor pattern is prone to class initialization deadlocks - here two threads are simultaneously attempting to initialize JAXWSLightSupport and JAXWSLightSupportAccessor, where each has a static initializer referring to the other.
Comment 3 Tomas Danek 2010-08-19 15:20:01 UTC
cannot reproduce any more.  I did some testing in maven-dev build (had open couple maven projects) , and then wanted to open web project (i work normally in 6.9.1) . Cannot give further information since it is not reproducible for me :(
Comment 4 Milan Kuchtiak 2010-08-20 10:33:11 UTC
> My suspicion is that this variant of the accessor pattern is prone to class
initialization deadlocks

I agree, the pattern looks suspicious.
However, we use the same pattern (not only with JAXWSLightSupport) in multiple places. If the pattern were incorrect we would need to fix (synchronize static initializers) all usages.

Closing as "works for me" as this is not a deadlock in fact.
If another similar issue, or deadlock, is observed, we'll need to look at this pattern seriously.
Comment 5 Milan Kuchtiak 2010-08-20 11:31:11 UTC
Oops, I found (wrote a simple test case) this variant is really Deadlock prone.
Comment 6 Milan Kuchtiak 2010-08-20 12:23:05 UTC
Comment 7 Quality Engineering 2010-08-21 03:42:57 UTC
Integrated into 'main-golden', will be available in build *201008210001* on (upload may still be in progress)
Log: #189679: fixed deadlock in Accessor pattern implementation

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo