[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
|
Hi Scott,
Please find my comment inline.
On 7/3/2020 5:24 PM, Scott Marlow
wrote:
They 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?
I'll make this change and will update you once its done.
We need to revert the change to use asadmin
--user admin --passwordfile /root/admin-password.txt
create-jvm-options -Ddeployment.resource.validation=false,
it is not working.
Scott
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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!OPOFfAeavYXC0cGY21JANwKf0t49dVoaf1O0GXXYkS_PNAAZN1dhAl-V8ME0S9tSNfg$
--
Thanks & Regards
Rohit Kumar Jain, Senior Member Of
Technical Staff
Mobile: 9036132401
Oracle WLS
India, Oracle India Pvt. Ltd., 560076 Bangalore