| Re: [jakartaee-tck-dev] Improving efficiency of TCK jobs and switching to build/run TCKs with https://www.eclipse.org/downloads/download.php?file=/ee4j/glassfish/glassfish-6.0.0-SNAPSHOT-nightly.zip |
On Thu, Jul 2, 2020 at 11:22 AM Alwin Joseph <alwin.joseph@xxxxxxxxxx> wrote:
On 02/07/20 7:46 am, Scott Marlow wrote:
Hi,
The build/run TCK jobs [1][2][3] are now updated to use the nightly GlassFish build.
Hi Scott, I updated the same to https://download.eclipse.org/ee4j/glassfish/glassfish-6.0.0-SNAPSHOT-nightly.zip. This should be the same as you were referring.
The both do seem the same to me as well (I downloaded both and they both contain files with today's date).
But the glassfish start domain gave the below exception after using this new bundle. Maybe if this nightly glassfish can possibly have issues we could fall back to M1 release?
Or we could try https://ci.eclipse.org/jakartaee-tck/job/build-glassfish/lastSuccessfulBuild/artifact/appserver/distributions/glassfish/target/glassfish.zip, which is from July 1. Perhaps we should add a Jenkins job parameter for GF_BUNDLE_URL, so that we can more easily try different builds of GlassFish if needed.Scott_______________________________________________[exec] Error starting domain domain1. [exec] The server exited prematurely with exit code 1. [exec] Before it died, it produced the following output: [exec] [exec] Launching GlassFish on Felix platform [exec] Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@221ee7b8 in service registry. [exec] Completed shutdown of GlassFish runtime [exec] We are in non-embedded mode, so org.glassfish.main.core.glassfish [103] has nothing to do...[exec] Exception in thread "main" java.lang.reflect.InvocationTargetException [exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [exec] at java.lang.reflect.Method.invoke(Method.java:498) [exec] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:73) [exec] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:30) [exec] Caused by: A MultiException has 2 exceptions. They are: [exec] 1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.config [165]], State = [NEW] [exec] 2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor( [exec] implementation=org.glassfish.jdbc.config.JdbcConnectionPoolInjector [exec] name=jdbc-connection-pool [exec] Caused by: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.config [165]], State = [NEW] [exec] at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:193) [exec] at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:54) [exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2234) [exec] ... 31 more [exec] Caused by: org.osgi.framework.BundleException: Unable to resolve org.glassfish.main.jdbc.config [165](R 165.0): missing requirement [org.glassfish.main.jdbc.config [165](R 165.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.connectors.config.validators)(version>=6.0.0)(!(version>=7.0.0))) [caused by: Unable to resolve org.glassfish.main.connectors.internal-api [46](R 46.0): missing requirement [org.glassfish.main.connectors.internal-api [46](R 46.0)] osgi.wiring.package; (&(osgi.wiring.package=com.sun.enterprise.deployment.runtime.connector)(version>=6.0.0)(!(version>=7.0.0))) [caused by: Unable to resolve org.glassfish.main.deployment.dol [70](R 70.0): missing requirement [org.glassfish.main.deployment.dol [70](R 70.0)] osgi.wiring.package; (&(osgi.wiring.package=jakarta.enterprise.inject.spi)(version>=3.0.0)(!(version>=4.0.0))) [caused by: Unable to resolve jakarta.enterprise.cdi-api [133](R 133.0): missing requirement [jakarta.enterprise.cdi-api [133](R 133.0)] osgi.wiring.package; (&(osgi.wiring.package=jakarta.el)(version>=4.0.0))]]] Unresolved requirements: [[org.glassfish.main.jdbc.config [165](R 165.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.connectors.config.validators)(version>=6.0.0)(!(version>=7.0.0)))]
Regarding efficiency of TCK jobs, we saw a hint that our TCK jobs may not be using correct memory settings. The hint is that increasing the JNLP memory size from 2176Mi to 3Gi [4], allowed the Full Platform TCK run to completion. Previously, for several test runs the JPA tests (running only with the appmanagedNoTx vehicle) would unexpectedly fail to deploy correctly. This sounds to me like we could be experiencing thrashing of some sort.
How can we can properly ensure that for all launched JVM processes (especially long running ones), we don't use more memory than is allowed by the OS (vm/container) that we are running on.
So, how can we get OS level statistics for the jakartaee-tck Jenkins jobs? It likely involves contacting cbi-dev@xxxxxxxxxxx which is fine but I wanted to ask here first, to raise awareness and get advice.
Scott
[1] https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master
[2] https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build-master
[3] https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-run-master
[4] https://github.com/eclipse-ee4j/jakartaee-tck/pull/347
_______________________________________________
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