Benoit Tellier created JAMES-3745:
-------------------------------------
Summary: FastByteArrayOutputStream is never downsized
Key: JAMES-3745
URL: https://issues.apache.org/jira/browse/JAMES-3745
Project: James Server
Issue Type: Improvement
Components: IMAPServer
Affects Versions: 3.7.0
Reporter: Benoit Tellier
Fix For: 3.8.0
I started studying production heap dump in an effort to reduce the per user
memory footprint. In conjunction with issues discussed in JAMES-3740 I found
that in FastByteArrayOutputStream, upon writing a long line this buffer is
sized up and never sized down.
We can end up with 60KB+ memory allocated per user... Forever.
While the impact is not as huge as the one described in JAMES-3740 yet for
James deployment with a high connection density this could be non neglictible
(100s MB of RAM).
Furthermore given the long lived lifecycle of this buffer (connection) it is
very likely to be promoted to the old gen, which could build up to eventually
get long GC pauses.
Suggestion: create a new IMAP composer for each request, 2 -> 64KB allocation
is anyway neglictibe, likely cheaper than the lookups to get them back! We will
thus allocate more memory, yes, but only for short lived durations, wich JVM GC
is really good at.
IMO it is so easy to avoid this unwanted behaviour that it would be sad not to
do it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
