Thanks for your answer... In the meantime I tried all 3 SSL connector implementations (JSSE implementation provided as part of the Java runtime, JSSE implementation that uses OpenSSL and APR implementation, which uses the OpenSSL engine by default). Same result!
Greetings Peter Am 05.02.20 um 15:06 schrieb Maxim Solodovnik: > Several users works for me > Local installation > Default self-signed cert > Default memory options (bin/catalina.sh run) > > Will double-check asap and report back > > > On Wed, Feb 5, 2020, 16:35 Peter Dähn <[email protected]> wrote: > >> Hi there, >> >> my testserver (Version: 5.0.0-M4-SNAPSHOT, Revision: cf78413, Builddate: >> 2020-02-03T10:46:21Z) running out of memory (see log underneath) after a >> few attendees logged in. This happen right after login and users just get >> the rotating balls. >> >> In standard-configuration this happens to the third attendee. It is >> reproducible for me. If one close its connection another can login. If I >> increase the heap memory the number of user that can sign in increases too. >> If I use 4GB heap memory the number of logged in users is 7. The 8th get >> the rotating balls... >> >> I configured tomcat to provide ssl in conf/server.xml. >> >> <Connector port="5443" >> protocol="org.apache.coyote.http11.Http11AprProtocol" >> maxThreads="150" SSLEnabled="true" scheme="https" >> secure="true"> >> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" >> /> >> <SSLHostConfig> >> <Certificate certificateKeyFile="domain.key" >> certificateFile="domain.pem" >> certificateChainFile="domain.chain.txt" >> type="RSA" /> >> </SSLHostConfig> >> </Connector> >> >> Java version is >> >> java.vm.name=OpenJDK 64-Bit Server VM >> java.version=11.0.6 >> >> >> SCHWERWIEGEND [https-openssl-apr-5443-exec-15] >> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Verarbeitung >> der Anfrage fehlgeschlagen >> java.lang.OutOfMemoryError: Java heap space >> at java.base/java.nio.HeapCharBuffer.<init>(HeapCharBuffer.java:61) >> at java.base/java.nio.CharBuffer.allocate(CharBuffer.java:348) >> at >> org.apache.tomcat.websocket.WsFrameBase.<init>(WsFrameBase.java:96) >> at >> org.apache.tomcat.websocket.server.WsFrameServer.<init>(WsFrameServer.java:45) >> at >> org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:128) >> at >> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:906) >> at >> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:1998) >> at >> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >> at java.base/java.lang.Thread.run(Thread.java:834) >> >> >> There is also some information in catalina.out beside the error message >> >> INFORMATION [hz.server-1.HealthMonitor] >> com.hazelcast.internal.diagnostics.HealthMonitor.null >> [131.246.123.153]:5701 [dev] [3.12.5] processors=4, >> physical.memory.total=0, physical.memory.free=0, swap.space.total=0, >> swap.space.free=0, heap.memory.used=3,6G, heap.memory.free=450,1M, >> heap.memory.total=4,0G, heap.memory.max=4,0G, >> heap.memory.used/total=89,01%, heap.memory.used/max=89,01%, >> minor.gc.count=0, minor.gc.time=0ms, major.gc.count=0, major.gc.time=0ms, >> load.process=0,00%, load.system=0,00%, load.systemAverage=1,14, >> thread.count=105, thread.peakCount=110, cluster.timeDiff=0, event.q.size=0, >> executor.q.async.size=0, executor.q.client.size=0, >> executor.q.client.query.size=0, executor.q.client.blocking.size=0, >> executor.q.query.size=0, executor.q.scheduled.size=0, executor.q.io.size=0, >> executor.q.system.size=0, executor.q.operations.size=0, >> executor.q.priorityOperation.size=0, operations.completed.count=1296, >> executor.q.mapLoad.size=0, executor.q.mapLoadAllKeys.size=0, >> executor.q.cluster.size=0, executor.q.response.size=0, >> operations.running.count=0, >> operations.pending.invocations.percentage=0,00%, >> operations.pending.invocations.count=0, proxy.count=0, >> clientEndpoint.count=0, connection.active.count=0, >> client.connection.count=0, connection.count=0 >> >> Any ideas? Is it reproducable by someone else? >> >> Greetings Peter >> -- >> B.Sc. Peter Dähn >> Virtueller Campus Rheinland-Pfalz <http://www.vcrp.de/> >> Postfach 3049 >> 67653 Kaiserslautern >> Tel: 0631/205-4944 >> Olat <https://olat.vcrp.de/> >>
