NP glad you find the reason :)) On Fri, 7 Feb 2020 at 14:56, Peter Dähn <da...@vcrp.de> wrote:
> Hi Maxim, > > I could figure it out. Of course it was my fault... > > Lately I changed the value of > org.apache.tomcat.websocket.binaryBufferSize in web.xml for a reason I > can't remember clearly :-( (probably something with disconnects and huge > uploads). Unfortunately I had a typo in the script, so the value that > was set was a "bit" huge and the following tests I made with one user > logged in... > > Sorry for stealing your time... > > Greetings Peter > > Am 06.02.20 um 18:43 schrieb Maxim Solodovnik: > > great news so far :)) > > > > On Thu, 6 Feb 2020 at 18:55, Peter Dähn <da...@vcrp.de> wrote: > > > >> Hi Maxim, > >> > >> this morning I made a fresh installation without any changes. And it > >> worked. > >> > >> By now I add my adaptions one by one. I'm almost finished and It it > >> seams to work. 12 user loges in, heap usage of ~250 kb... > >> > >> I'm going to finish and give a final report, but by now it seams that > >> the issue is disappeared. > >> > >> Greetings Peter > >> > >> Am 05.02.20 um 15:44 schrieb Maxim Solodovnik: > >>> Just have tried > >>> > >>> > >> > https://builds.apache.org/view/M-R/view/OpenMeetings/job/openmeetings/2997/ > >>> H2 DB (default) > >>> 3 tab in Chrome, 3 tabs in Chromium > >>> 965M of RAM according to Ubuntu System monitor > >>> > >>> Ubuntu 20.04 alpha (but I believe it doesn't matter) > >>> I don't have any real cert so using default one > >>> > >>> It OM works for you without any changes? > >>> > >>> On Wed, 5 Feb 2020 at 21:25, Peter Dähn <da...@vcrp.de> wrote: > >>> > >>>> 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 <da...@vcrp.de> 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/> > >>>>>> > >> > >> > > > -- WBR Maxim aka solomax
