Due to the Oracle JRE license topic (Commercial User End of Public Updates), our company decided not to offer Oracle JRE on the windows workstations anymore.On the part of the internal IT only OpenJDK+IcedTea is provided.
We have tested Spectrum OneClick 10.2.1 with OpenJDK+IcedTea.Generally the Spectrum OneClick starts, but the start time in our environment has worsened from currently about 20 seconds (Oracle JRE 1.8.0_181) to about 6 minutes (OpenJDK 1.8.0_191 + IcedTea 1.7.2).
The analysis of the log files shows anomalies.IcedTea always seems to send all its requests as HEAD requests to the Tomcat server first. The Tomcat server rejects HEAD requests. After that a fallback on GET requests occurs. All IcedTea requests are always sent twice to the Tomcat server and also processed twice by the IcedTea.
This behavior is different from Oracle JRE. There, all requests are made as GET requests only once..class and .properties files are not requested individually from the server.Has anyone seen similar anomalies? Does anyone have an idea or a tip on how to positively influence the above described behavior?
Examples from Tomcat Logtomcat/logs> cat localhost_access_log.2019-01-31.txt | grep clientbluct.jarClient-IP address - - [31/Jan/2019:13:21:34 +0100] HEAD /spectrum/lib/contrib/clientbluct.jar;no_javaws_cheat HTTP/1.1 403 - 1Client-IP address - - [31/Jan/2019:13:23:00 +0100] HEAD /spectrum/lib/contrib/clientbluct.jar;no_javaws_cheat HTTP/1.1 403 - 5Client-IP address - - [31/Jan/2019:13:24:03 +0100] GET /spectrum/lib/contrib/clientbluct.jar;no_javaws_cheat HTTP/1.1 200 24222 1Client-IP address - - [31/Jan/2019:13:25:17 +0100] GET /spectrum/lib/contrib/clientbluct.jar;no_javaws_cheat HTTP/1.1 200 24222 2...
The log also contains some incorrect requests that the Tomcat server answered with HTTP 400. Examples:Client-IP address - - [31/Jan/2019:13:08:30 +0100] - 400 - 0Client-IP address - - [31/Jan/2019:13:08:31 +0100] - 400 - 0Client-IP address - - [31/Jan/2019:13:08:32 +0100] - 400 - 0Client-IP address - - [31/Jan/2019:13:08:34 +0100] - 400 - 0Client-IP address - - [31/Jan/2019:13:08:39 +0100] - 400 - 0...
tomcat/logs> cat localhost_access_log.2019-01-31.txt | grep .classClient-IP address - - [31/Jan/2019:13:26:21 +0100] GET /spectrum/com/aprisma/spectrum/app/console/client/package.class HTTP/1.1 404 1023 1Client-IP address - - [31/Jan/2019:13:26:22 +0100] GET /spectrum/com/aprisma/spectrum/app/console/client/package_en.class HTTP/1.1 404 1029 1Client-IP address - - [31/Jan/2019:13:26:23 +0100] GET /spectrum/com/aprisma/spectrum/app/console/client/package_en_US.class HTTP/1.1 404 1035 1...
tomcat/logs> cat localhost_access_log.2019-01-31.txt | grep .propertiesClient-IP address - - [31/Jan/2019:13:26:20 +0100] HEAD /spectrum/com/aprisma/spectrum/app/client/jnlp/package.properties HTTP/1.1 403 - 2Client-IP address - - [31/Jan/2019:13:26:20 +0100] HEAD /spectrum/com/aprisma/spectrum/app/client/jnlp/package_en.properties HTTP/1.1 403 - 5...
Did you try OneClick WebApp with CA Spectrum 10.3.1 release?
we would try the OneClick webapp, but currently have a general problem with Spectrum 10.3.1.
Our Spectrum environment runs under SLES11. Currently there is an open ticket (Case Number 01285970 - SpectroSERVER does not start with process owner spectrum).Therefore we can't test the OneClick webapp extensively yet and it will be a challenge for us to get Spectrum 10.3.1 into production soon.