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/>
>>>>>>
>>
>>


Reply via email to