Hi Mark,
as I stumbled upon this issue while searching for the reason of out of
memory conditions, I cannot rule out other things are part of the problem
here, too.
Sooner or later Tomcat is crashing because memory is filled up - which
obviously is the real problem. I wouldn’t mind sessions being stored “too
long”.
But when sessions aren’t destroyed even hours after the last request (with
session timeout set to 3 minutes), something’s wrong here nevertheless.
The setenv.sh is like this:
============ 8< ======================
CATALINA_OPTS=“-Xms1512m -Xmx1512m
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/heapdumps
-Djava.security.egd=file:/dev/./urandom
-javaagent:lib/lucee-inst.jar
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=5022
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=localhost”;
export CATALINA_OPTS;
============ 8< ======================
The JXM remote management config was used to connection VisualVM to the
server better see what’s going on here.
So I’ll try to install FusionReactor to get a better insight in to what
really is using up all the memory.
I never used FR before - any hints regarding where to look? As the FR
website states “FusionReactor is not built for memory analysis down to the
object level.”
I had thought FR only would allow me to see IF there are those kinds of
problems, and I would have to start taking apart a heap dump to see what’s
really
hogging all this memory.
Having started to take apart a heap dump with VisualVM, I still have a hard
time pointing my finger on something.
One thing I noted was there were a LOT of strings containing typical data
That really was the point where I started to look after how many sessions
were active and came across the original topic here - sessions accumulating
and not being destroyed.
Unfortunately I don’t have a chart/log of sessions over time. But -
depending on usage - the estimated session creation rate could have been
about 1 to 3 sessions/sec I guess.
I would have to implement logging for this, but don’t see how it would
affect the problem?
Christianfrom my sessions.
Am Dienstag, 20. September 2016 17:11:50 UTC+2 schrieb Mark Drew:
Hi there
“The first thing you should do is actually see what is in the memory or
what is filling it up. Can you post your setenv.sh ? Also you should
install Fusion Reactor to see what is really going on.
Is the actual problem getting out of memory problems rather than sessions
being stored? Could be anything that is filling up the memory rather than
just sessions?
If you are counting the sessions, do you have a log of session over time?
How much is in each session too? Does shortening the session time help?
MD
On 20 Sep 2016, at 14:52, ‘Christian Meis’ via Lucee < lu...@googlegroups.com <javascript:>> wrote:
The app is using CFML sessions with a session timeout of 180 seconds. It’s
being used by thousands of users over each day, but every
single interaction is rather short with the user just clicking through 2
or 3 pages.
Now for the problem:
It looks like sessions never expire and session data is being kept
forever. This leads to the heap filling up and sometime further down the
road Tomcat will just crash with an OOM.
I don’t see a reason why the sessions shouldn’t timeout.