-
Bug
-
Resolution: Duplicate
-
P2
-
None
-
6
-
sparc
-
solaris_8
From mustang b25, SAP J2EE engine fails to start completely.
Test machine: big5server.sfbay.sun.com
big5server:e03adm 4% uname -a
SunOS big5server 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-Enterprise
big5server:e03adm 5% /usr/j2se/bin/java -d64 -version
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b25)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-ea-b25, mixed mode)
SAP J2EE engine version:
J2EE Engine Version 6.30 PatchLevel 83087.313 is running
The J2EE engine is 64 bits kernel, it ONLY works with 64 bits JVM.
Error messages in output: ( There is no messages from VM, the error messages
are not very helpful to us )
...
Cannot start service dbpool; it has hard reference to service connector which
is not started.
Cannot start service com.sap.security.core.ume.service; it has hard reference
to service dbpool which is not started.
Cannot start service security; it has hard reference to service com.sap.securi
ty.core.ume.service which is not started.
Cannot start service keystore; it has hard reference to service security which
is not started.
Cannot start service ssl; it has hard reference to service keystore which is n
ot started.
Cannot start service applocking; it has hard reference to service security whi
ch is not started.
This is a regression from b24.
I would suggest hold off on the investigation on this for a while. The reasons are:
1. J2EE 6.30 is not a shipping product. We are currently in the process of upgrading to J2EE 6.40. Because of that, the test machine was not available for a few weeks, that is why the bug is not uncovered until now.
2. It's hard to find out if this is a compiler bug. J2EE engine 6.30 can not
be started with "-d64 -Xint". It will deadlock in classloaders each time -Xint is used.
SAP had flawed classloader a year ago. The deadlock is very likely a flaw in the application itself. But the problem blocks our experiments with intepreter. So
it's hard to tell if the problem is in runtime, or compiler, or even in the application itself.
Hopefully we can do tests with -Xint with J2EE 6.40 engine.
I will redo tests once J2E 6.40 is set up, and update the CR.
Meanwhile, I will still try to find out if there is anyway to localize the problem.
###@###.### 2005-03-19 01:47:44 GMT
Test machine: big5server.sfbay.sun.com
big5server:e03adm 4% uname -a
SunOS big5server 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-Enterprise
big5server:e03adm 5% /usr/j2se/bin/java -d64 -version
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b25)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-ea-b25, mixed mode)
SAP J2EE engine version:
J2EE Engine Version 6.30 PatchLevel 83087.313 is running
The J2EE engine is 64 bits kernel, it ONLY works with 64 bits JVM.
Error messages in output: ( There is no messages from VM, the error messages
are not very helpful to us )
...
Cannot start service dbpool; it has hard reference to service connector which
is not started.
Cannot start service com.sap.security.core.ume.service; it has hard reference
to service dbpool which is not started.
Cannot start service security; it has hard reference to service com.sap.securi
ty.core.ume.service which is not started.
Cannot start service keystore; it has hard reference to service security which
is not started.
Cannot start service ssl; it has hard reference to service keystore which is n
ot started.
Cannot start service applocking; it has hard reference to service security whi
ch is not started.
This is a regression from b24.
I would suggest hold off on the investigation on this for a while. The reasons are:
1. J2EE 6.30 is not a shipping product. We are currently in the process of upgrading to J2EE 6.40. Because of that, the test machine was not available for a few weeks, that is why the bug is not uncovered until now.
2. It's hard to find out if this is a compiler bug. J2EE engine 6.30 can not
be started with "-d64 -Xint". It will deadlock in classloaders each time -Xint is used.
SAP had flawed classloader a year ago. The deadlock is very likely a flaw in the application itself. But the problem blocks our experiments with intepreter. So
it's hard to tell if the problem is in runtime, or compiler, or even in the application itself.
Hopefully we can do tests with -Xint with J2EE 6.40 engine.
I will redo tests once J2E 6.40 is set up, and update the CR.
Meanwhile, I will still try to find out if there is anyway to localize the problem.
###@###.### 2005-03-19 01:47:44 GMT
- duplicates
-
JDK-6237956 mustang b25 cannot extract data from zip files created by third-party zip implementations
- Closed