Community
Participate
Working Groups
An adopter product is now running into the situation where the initialization of CommonPacakgeImpl is causing a deadlock. 3XMTHREADINFO "main" J9VMThread:0x41591300, j9thread_t:0x0001504C, java/lang/Thread:0x00556868, state:CW, prio=6 3XMTHREADINFO1 (native thread ID:0x1B58, native priority:0x6, native policy:UNKNOWN) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Object.wait(Native Method) 4XESTACKTRACE at java/lang/Object.wait(Bytecode PC:3(Compiled Code)) 4XESTACKTRACE at java/lang/J9VMInternals.initialize(Bytecode PC:3(Compiled Code)) 4XESTACKTRACE at sun/misc/Unsafe.ensureClassInitialized(Native Method) 4XESTACKTRACE at sun/reflect/UnsafeFieldAccessorFactory.newFieldAccessor(Bytecode PC:79(Compiled Code)) 4XESTACKTRACE at sun/reflect/ReflectionFactory.newFieldAccessor(Bytecode PC:5(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.acquireFieldAccessor(Bytecode PC:94(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.getFieldAccessor(Bytecode PC:36(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.get(Bytecode PC:2) 4XESTACKTRACE at org/eclipse/emf/ecore/plugin/RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) 4XESTACKTRACE at org/eclipse/emf/ecore/impl/EPackageImpl$1.getEPackage(EPackageImpl.java:168) 4XESTACKTRACE at org/eclipse/emf/ecore/impl/EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) 4XESTACKTRACE at org/eclipse/jst/j2ee/common/internal/impl/CommonPackageImpl.initializePackageContents(CommonPackageImpl.java:1332) 4XESTACKTRACE at org/eclipse/jst/j2ee/common/internal/impl/CommonPackageImpl.init(CommonPackageImpl.java:297) 4XESTACKTRACE at org/eclipse/jst/j2ee/common/CommonPackage.<clinit>(CommonPackage.java:243) 4XESTACKTRACE at java/lang/J9VMInternals.initializeImpl(Native Method) 4XESTACKTRACE at java/lang/J9VMInternals.initialize(Bytecode PC:297(Compiled Code)) 3XMTHREADINFO "Thread-18" J9VMThread:0x46BBC000, j9thread_t:0x45C0DF90, java/lang/Thread:0x3FBF8280, state:CW, prio=6 3XMTHREADINFO1 (native thread ID:0x494, native priority:0x6, native policy:UNKNOWN) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Object.wait(Native Method) 4XESTACKTRACE at java/lang/Object.wait(Bytecode PC:3(Compiled Code)) 4XESTACKTRACE at java/lang/J9VMInternals.initialize(Bytecode PC:3(Compiled Code)) 4XESTACKTRACE at sun/misc/Unsafe.ensureClassInitialized(Native Method) 4XESTACKTRACE at sun/reflect/UnsafeFieldAccessorFactory.newFieldAccessor(Bytecode PC:79(Compiled Code)) 4XESTACKTRACE at sun/reflect/ReflectionFactory.newFieldAccessor(Bytecode PC:5(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.acquireFieldAccessor(Bytecode PC:94(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.getFieldAccessor(Bytecode PC:36(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.get(Bytecode PC:2) 4XESTACKTRACE at org/eclipse/emf/ecore/plugin/RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) 4XESTACKTRACE at org/eclipse/emf/ecore/impl/EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) 4XESTACKTRACE at org/eclipse/jst/j2ee/webservice/wsclient/internal/impl/Webservice_clientPackageImpl.initializePackageContents(Webservice_clientPackageImpl.java:452) 4XESTACKTRACE at org/eclipse/jst/j2ee/webservice/wsclient/internal/impl/Webservice_clientPackageImpl.init(Webservice_clientPackageImpl.java:141) 4XESTACKTRACE at org/eclipse/jst/j2ee/webservice/wsclient/Webservice_clientPackage.<clinit>(Webservice_clientPackage.java:75) 4XESTACKTRACE at java/lang/J9VMInternals.initializeImpl(Native Method) 4XESTACKTRACE at java/lang/J9VMInternals.initialize(Bytecode PC:297(Compiled Code)) 4XESTACKTRACE at sun/misc/Unsafe.ensureClassInitialized(Native Method) 4XESTACKTRACE at sun/reflect/UnsafeFieldAccessorFactory.newFieldAccessor(Bytecode PC:79(Compiled Code)) 4XESTACKTRACE at sun/reflect/ReflectionFactory.newFieldAccessor(Bytecode PC:5(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.acquireFieldAccessor(Bytecode PC:94(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.getFieldAccessor(Bytecode PC:36(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Field.get(Bytecode PC:2) 4XESTACKTRACE at org/eclipse/emf/ecore/plugin/RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:274) 4XESTACKTRACE at org/eclipse/emf/ecore/impl/EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:133) 4XESTACKTRACE at org/eclipse/jst/j2ee/internal/J2EEInit$20.run(J2EEInit.java:343) 4XESTACKTRACE at java/lang/Thread.run(Bytecode PC:13)
Created attachment 185569 [details] Remove Webservice_clientPackageImpl from the separate init thread In bug 315286, I put in a directed ordering of the initialization. The only part that I was unsure of how to handle was CommonPackageImpl and Webservices_clientPackageImpl initializations- the latter requires quite a few fields of the former, but the former requires one field of the latter, thus there is no good way to initialize the two of them in a directed manner. The problem here is that CommonPackageImpl is being initialized, it kicks off J2EEInit.initEMFModels(), which quickly initializes Webservices_clientPackageImpl, and the two deadlock. Switching their order only moves the problem from one place to another. My solution is simple- remove Webservices_clientPackageImpl from J2EEInit.initEMFModels(). This will ensure that CommonPackageImpl is initialized first... and the initialization of Webservices_clientPackageImpl will be done as part of CommonPackageImpl.initializePackageContents().
approve
Committed to R3_2_maintenance and HEAD for WTP 3.2.3 and WTP 3.3 M5
