[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
|
I can confirm that removing testsuite.jtd from my environment has no apparent effect on the behavior that I'm seeing.
-Brian
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
Lance Andersen ---05/22/2020 06:23:31 AM---> On May 21, 2020, at 7:50 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote: >
From: Lance Andersen <lance.andersen@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/22/2020 06:23 AM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
On May 21, 2020, at 7:50 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote:
"Well from the above you cannot tell if the failure occurs within the harness or somewhere with CTS
Be interesting to know if it you get any further by removing testsuite.jtd"
com.sun.ts.lib.harness.TSScript.invokeCommand() launches a Java process. From attaching a debugger to that launched process, I can see that it immediately runs into the StackOverflowError before doing anything else. If you glue the top and bottom of the stack that I provided together, you'll see that it entirely consists of JDK internals. It's not executing any harness or CTS code at all before it blows up. I don't know what the JDK code in question is trying to do or why it loops through itself a bunch of times with either flavor of Java 11.
I would still try removing testsuite.jtd and see if you see the same behavior when the binary finder is not there. One of the first things needed to be done by jtharness is find the available tests, When running CTS or any standalone TCK out of a workspace, the binary finder is not used
"What version of javatest is being used? 4.6 or 5?"
Whichever one is included in the 8.0.2 TCK, and that appears to be version 5.
re: other TCKs
The only other TCKs we typically run separately are BeanValidation and CDI both of which use an entirely different testing mechanism (Arquillian, etc.), so I'm skeptical as to whether they'd be useful for this discussion, but they are on my to-do list.
Given BV and CDI TCKs do not use jtharness, yes that is not applicable.
I am referring to TCKs such as JPA, Servlet, JSF, etc which use jtharness. Assuming it is the same version of javatest, This could be helpful in narrowing down the issue
Best
Lance
-Brian
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
<graycol.gif>Lance Andersen ---05/21/2020 06:22:02 PM---> On May 21, 2020, at 1:04 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote: >
From: Lance Andersen <lance.andersen@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/21/2020 06:22 PM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
:-)
"The stack trace below does not appear to be the full stack trace"
This is true, I only showed the very bottom of the stack to show that this is indeed occurring right from trying to load the main class before it gets anywhere into actual test/framework code. From etc. up it just repeats what I already showed a bajillion times, resulting in something like this at the top:
Exception in thread "main" java.lang.StackOverflowError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at java.base/java.net.URL.lookupViaProperty(URL.java:1257)
at java.base/java.net.URL.getURLStreamHandler(URL.java:1416)
at java.base/java.net.URL.<init>(URL.java:451)
at java.base/jdk.internal.loader.URLClassPath$JarLoader.<init>(URLClassPath.java:719)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444)
at java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:695)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at java.base/java.net.URL.lookupViaProperty(URL.java:1261)
at java.base/java.net.URL.getURLStreamHandler(URL.java:1416)
at java.base/java.net.URL.<init>(URL.java:451)
...
Well from the above you cannot tell if the failure occurs within the harness or somewhere with CTS
Be interesting to know if it you get any further by removing testsuite.jtd
"Does this occur when running against any other App Server such as Glassfish?"
No idea. Our intention was to inform the community so they could go see if they have the same problem when trying to run with their app servers. Glassfish doesn't support Java 11 yet, does it?
Not sure if JDK 11 support is there for Glassfish.
"Is it possible the issue is being influenced by the porting package for Open Liberty?"
Anything's possible I suppose, but considering it's not even loading the main class after this Java process is spawned, I don't see how. People trying this with their own app server/porting package would be a useful data point for this. It's easily reproducible for us just by trying to run the EE8 TCK with Java 11.
"How is the TCK being run: the command line via tsant or the GUI?"
Command line. This was first detected in our automated runs, which all use the command line.
It would be worth trying to start the GUI and see where you get.
What version of javatest is being used? 4.6 or 5?
"If you are running java test from the command line, do you see the same issue if you just start up the GUI without running a test?"
No idea. I'm relatively new in this role and have never tried to do anything with the GUI.
"Do you notice the same issue running one of the standalone TCKs or just the platform TCK? Same issue when running in Web Profile mode?"
I haven't tried any other TCKs or modes with Java 11 yet. It's early days.
This would be a good thing to try as a datapoint or try Web Profile mode
"Have you tried to narrow down the issue with a simplified test case as it would be useful to see understand the difference between J9 and Hotspot. This would be useful if possible"
No, I haven't. I've been working with some Java contacts internal to us, but we haven't gotten that far yet. For what it's worth, I have attached a debugger to both and I can see the stack growing with the same URL.<init>-related stack in both. It just apparently doesn't get nearly as big in J9 before doing whatever it's trying to do.
"What other differences to you have in your ts.jte configuration between JDK 8 and 11?"
Very little. All that's needed to get things to run is removing the -Djava.endorsed.dirs argument, as it's no longer supported.
-Brian
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
<graycol.gif>Lance Andersen ---05/21/2020 06:50:41 AM---Hi Brian, A few questions.
From: Lance Andersen <lance.andersen@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/21/2020 06:50 AM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
Hi Brian,
A few questions.
The stack trace below does not appear to be the full stack trace
Does this occur when running against any other App Server such as Glassfish?
Is it possible the issue is being influenced by the porting package for Open Liberty?
How is the TCK being run: the command line via tsant or the GUI?
If you are running java test from the command line, do you see the same issue if you just start up the GUI without running a test?
Do you notice the same issue running one of the standalone TCKs or just the platform TCK? Same issue when running in Web Profile mode?
Have you tried to narrow down the issue with a simplified test case as it would be useful to see understand the difference between J9 and Hotspot. This would be useful if possible
What other differences to you have in your ts.jte configuration between JDK 8 and 11?
Best
Lance
On May 20, 2020, at 5:32 PM, Brian M Decker <bmdecker@xxxxxxxxxx> wrote:
I've been the one tinkering with this for us [IBM], and here's what I've found so far.
The problem is specific to running with Java 11. I've found that using -Xss1088k with the Hotspot JDK is sufficient to avoid the error. This is just a touch above the default value of 1024k; however, it is a massive step up from what is needed with Java 8. I am able to run the TCK just fine while specifying the minimum allowed value of -Xss228k with Hotspot Java 8.
I also took some diagnostics using the OpenJ9 version of both Java 8 and Java 11 and see a similar uptick there, although both needed stacks far smaller than the corresponding Hotspot release, which is how it has served as a workaround without needing to change java options.
OpenJ9 JDK 8: ~5k
OpenJ9 JDK 11: ~187k
It is sufficient to add the -Xss argument into command.testExecute in ts.jte. That's what I've been doing locally to test all of this out. The problem occurs when running any test in the entire TCK as it occurs when first trying to initialize and load classes:
... etc.
[23] java.lang.ClassLoader.loadClass (ClassLoader.java:521)
[24] java.net.URL.lookupViaProperty (URL.java:1,261)
[25] java.net.URL.getURLStreamHandler (URL.java:1,416)
[26] java.net.URL.<init> (URL.java:451)
[27] jdk.internal.loader.URLClassPath$JarLoader.<init> (URLClassPath.java:719)
[28] jdk.internal.loader.URLClassPath$3.run (URLClassPath.java:493)
[29] jdk.internal.loader.URLClassPath$3.run (URLClassPath.java:476)
[30] java.security.AccessController.doPrivileged (native method)
[31] jdk.internal.loader.URLClassPath.getLoader (URLClassPath.java:475)
[32] jdk.internal.loader.URLClassPath.getLoader (URLClassPath.java:444)
[33] jdk.internal.loader.URLClassPath.getResource (URLClassPath.java:313)
[34] jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull (BuiltinClassLoader.java:695)
[35] jdk.internal.loader.BuiltinClassLoader.loadClassOrNull (BuiltinClassLoader.java:621)
[36] jdk.internal.loader.BuiltinClassLoader.loadClass (BuiltinClassLoader.java:579)
[37] jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass (ClassLoaders.java:178)
[38] java.lang.ClassLoader.loadClass (ClassLoader.java:521)
[39] java.lang.Class.forName0 (native method)
[40] java.lang.Class.forName (Class.java:398)
[41] sun.launcher.LauncherHelper.loadMainClass (LauncherHelper.java:760)
[42] sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:655)
Brian Decker
Rochester Blizzard
Jakarta Platform TCK Lead
Home Office
(612) 216-4881
Roch. Office
t/l 553-4686
bmdecker@xxxxxxxxxx
<graycol.gif>Alwin Joseph ---05/20/2020 03:58:36 PM---Hi Kevin, Oops sorry. Yes, I was referring to the heap memory setting we used for
From: Alwin Joseph <alwin.joseph@xxxxxxxxxx>
To: Kevin Sutter <sutter@xxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 05/20/2020 03:58 PM
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
Hi Kevin,
Oops sorry. Yes, I was referring to the heap memory setting we used for Jakarta EE 8 TCK runs. ( we are yet to run Platform TCK for Jakarta EE 9).
I cannot find any configurable setting to alter the stack size (-Xss) within the TCK. We could check if the test run commands in ts.jte (command.testExecute*) can be made use of, to add the stack size.
Can you share details of the default stack size that was changed for IBM run if the change was within the TCK source. It would also help to know for future reference, which specific tests needed the change in stack size to run.
Regards,
Alwin Joseph
On 21/05/20 1:26 AM, Kevin Sutter wrote:
Thanks, Alwin.
The options you referenced are for the "heap size", not the "stack size". The scripts you referenced do not seem to be setting the "stack size" (-Xss), so maybe that's being set outside of these scripts as just part of the environment configuration?
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Alwin Joseph <alwin.joseph@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Kevin Sutter <sutter@xxxxxxxxxx>
Date: 05/20/2020 13:51
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] stack size for running the Platform TCK for Jakarta EE 9?
Hi Kevin,
For running platform TCK against glassfish we change the default memory settings in VI, RI and the TCK only for ejb30 tests. This configuration change is done from [1] to [2]. The maximum memory is increased in the bin/ts.jte for the TCK to Xmx4096m for the platform TCK run in CI [2].
[1] https://github.com/eclipse-ee4j/jakartaee-tck/blob/38cb27458e1ace61de3eb767713136c9484d130e/docker/run_jakartaeetck.sh#L251
[2] https://github.com/eclipse-ee4j/jakartaee-tck/blob/38cb27458e1ace61de3eb767713136c9484d130e/docker/run_jakartaeetck.sh#L259
HTH,
Alwin Joseph
On 20/05/20 11:58 PM, Kevin Sutter wrote:
Hi,
Does anybody know the stack size that is used when running the Platform TCK for Jakarta EE 9? Some of you know that we (IBM) have been hitting a couple of issue when attempting to run the TCK with HotSpot (works with OpenJ9). We've recently discovered that we can get around the problem by doubling the default stack size to 2048k (-Xss2048k). Since everyone's environment might be setup slightly different, I'm wondering what our Jakarta EE runs use for the stack size? And, whether this is a configurable item that needs to be updated somewhere in the TCK configuration? Or, maybe it's already set at a higher value and our (IBM) environment was out of sync. Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
<1C706724.gif>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
<1C222967.gif>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
