Try out following command. Entry with * is the java version your system
is set to use. You can use same command to config alternate version.
update-alternatives --config java
We routinely use multiple versions of JDK on many systems. We just set
JAVA_HOME and derive all paths from that. Works
On 11/06/2021 21:53, Joel Griffith wrote:
Hi everyone,
I have two Ubuntu 20.04 servers, both with Tomcat 9 and Java 8 installed
from the standard repositories.
On the first, I installed Java 8 before installing Tomcat 9. When I
installed Tomcat 9, it evidently found the existing Java 8 install
On 11/06/2021 21:01, Mark A. Claassen wrote:
RESOLVED. (Sort of, I have questions)
I had to add a -TLSv1.3
protocols="all -SSLv3 -TLSv1 -TLSv1.3"
https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable
Why does the
Hi everyone,
I have two Ubuntu 20.04 servers, both with Tomcat 9 and Java 8 installed
from the standard repositories.
On the first, I installed Java 8 before installing Tomcat 9. When I
installed Tomcat 9, it evidently found the existing Java 8 installation,
and when I run the server it reports
RESOLVED. (Sort of, I have questions)
I had to add a -TLSv1.3
protocols="all -SSLv3 -TLSv1 -TLSv1.3"
https://stackoverflow.com/questions/57601284/java-11-and-12-ssl-sockets-fail-on-a-handshake-failure-error-with-tlsv1-3-enable
Why does the version of Tomcat matter? I thought OpenSSL wa
I have tried so many things, I am getting a bit confused. :)
The exception was probably using the NIO connector. With the APR one I get:
FINER: Destroying socket [140,404,292,849,904]
java.lang.Exception
at
org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint.java:750
I turned all the logging to .FINEST, re-enabled the HTTP APR connector (which
produces the odd access log entry) and got this exception. Now, I just need to
figure out what caused this.
java.io.EOFException
at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEn
jProfiler shows the threads are stuck with high cpu usage on. I am using
HikariCp connection pool management 3.1.0
org.postgresql.jdbc.PgPreparedStatement.execute
I am using 42.2.21 version of jdbc driver
Below is the Java code
Connection con = null;
CallableStatement callableStatement = null;
On 06/05/2021 14:36, Mark Thomas wrote:
It's probably worth us taking some time to adapt markt's SO answer
there into a whole section on "Protocol Abuse and Protection Features"
in the HTTP/2 configuration guide.
There is an open issue for Chrome:
https://bugs.chromium.org/p/chromium/issues