You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@openmeetings.apache.org by Peter Dähn <da...@vcrp.de> on 2020/02/05 09:37:49 UTC
Error Message OutOfMemoryError: Java heap space
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/>
Re: information in services/info/health
Posted by Peter Dähn <da...@vcrp.de>.
good point.. then I keep it like it is and take it out of the logfiles...
But maybe something like jvm ok/nok is possible?
By default Dhazelcast.health.monitoring.level is set to "silence" and
information will be logged as warning, if a given threshold is reached.
Maybe this could trigger a "jvm: nok"?
Greetings Peter
Am 07.02.20 um 10:25 schrieb Maxim Solodovnik:
> Hello Peter,
>
> IMO this might be sensitive information
> Are you sure this should be available without authorization?
>
> On Fri, 7 Feb 2020 at 16:18, Peter Dähn <da...@vcrp.de> wrote:
>
>> Hi Maxim,
>>
>> during my little research I used the information of hazelcast
>> HealthMonitor...
>>
>> 07-Feb-2020 09:27:17.941 INFORMATION [hz.server-1.HealthMonitor]
>> com.hazelcast.internal.diagnostics.Healthmonitor.null [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=367,4M,
>> heap.memory.free=273,6M, heap.memory.total=641,0M, heap.memory.max=2,9G,
>> heap.memory.used/total=57,27%, heap.memory.used/max=12,22%,
>> 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=0,18, thread.count=95, thread.peakCount=105,
>> 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=261,
>> 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
>>
>>
>> Is it possible to put those information in
>> OM_SERVER_ADDRESS/services/info/health ?
>>
>> Greetings Peter
>>
>>
>>
>>
Re: information in services/info/health
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Peter,
IMO this might be sensitive information
Are you sure this should be available without authorization?
On Fri, 7 Feb 2020 at 16:18, Peter Dähn <da...@vcrp.de> wrote:
> Hi Maxim,
>
> during my little research I used the information of hazelcast
> HealthMonitor...
>
> 07-Feb-2020 09:27:17.941 INFORMATION [hz.server-1.HealthMonitor]
> com.hazelcast.internal.diagnostics.HealthMonitor.null [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=367,4M,
> heap.memory.free=273,6M, heap.memory.total=641,0M, heap.memory.max=2,9G,
> heap.memory.used/total=57,27%, heap.memory.used/max=12,22%,
> 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=0,18, thread.count=95, thread.peakCount=105,
> 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=261,
> 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
>
>
> Is it possible to put those information in
> OM_SERVER_ADDRESS/services/info/health ?
>
> Greetings Peter
>
>
>
>
--
WBR
Maxim aka solomax
information in services/info/health
Posted by Peter Dähn <da...@vcrp.de>.
Hi Maxim,
during my little research I used the information of hazelcast
HealthMonitor...
07-Feb-2020 09:27:17.941 INFORMATION [hz.server-1.HealthMonitor]
com.hazelcast.internal.diagnostics.HealthMonitor.null [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=367,4M,
heap.memory.free=273,6M, heap.memory.total=641,0M, heap.memory.max=2,9G,
heap.memory.used/total=57,27%, heap.memory.used/max=12,22%,
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=0,18, thread.count=95, thread.peakCount=105,
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=261,
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
Is it possible to put those information in
OM_SERVER_ADDRESS/services/info/health ?
Greetings Peter
Re: Error Message OutOfMemoryError: Java heap space
Posted by Maxim Solodovnik <so...@gmail.com>.
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
Re: Error Message OutOfMemoryError: Java heap space
Posted by Peter Dähn <da...@vcrp.de>.
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/>
>>>>>>
>>
>>
Re: Error Message OutOfMemoryError: Java heap space
Posted by Maxim Solodovnik <so...@gmail.com>.
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
Re: Error Message OutOfMemoryError: Java heap space
Posted by Peter Dähn <da...@vcrp.de>.
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/>
>>>>
>>
Re: Error Message OutOfMemoryError: Java heap space
Posted by Maxim Solodovnik <so...@gmail.com>.
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
Re: Error Message OutOfMemoryError: Java heap space
Posted by Peter Dähn <da...@vcrp.de>.
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/>
>>
Re: Error Message OutOfMemoryError: Java heap space
Posted by Maxim Solodovnik <so...@gmail.com>.
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/>
>