[
https://issues.apache.org/jira/browse/DIRMINA-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652781#action_12652781
]
Emmanuel Lecharny commented on DIRMINA-641:
-------------------------------------------
This is a real issue. I have checked the JZLib code quickly, and I must say I'm
frighten by what I have saw ... Initializing the deflater will sucks something
like 200K at least, and if you have 6K sessions, then you will quickly reach a
level of memory usage which will be insane.
If we consider that deflating a steam is totally stateless (ie, once the stream
has been deflated, we don't care about the built tables inside the deflater),
we could certainly discard the deflater after each deflated message. The
problem is to know when the message has been completely deflated...
I'm not even sure that the deflater simply works if we receive an inflated
message piece by piece. How does the mina inflater manage this case ? I don't
know ...
> Configurable memory limit for CompressionFilter
> -----------------------------------------------
>
> Key: DIRMINA-641
> URL: https://issues.apache.org/jira/browse/DIRMINA-641
> Project: MINA
> Issue Type: Wish
> Components: Filter
> Affects Versions: 1.0.10, 1.1.7, 2.0.0-M3
> Environment: Cross-platform
> Reporter: Mauritz Lovgren
>
> Currently, there is a large build-up of memory due to the fact that
> CompressionFilter (or morewhat jzlib) builds up memory structures for
> efficient compression over time.
> The problem arises when using thousands of connections, as the
> CompressionFilter keeps compression data per IoSession, holding several
> hundreds of megabytes from being GCed.
> Would help a lot if maximum amount of memory cached by ZStream could be
> configurable. Would rather have small memory footprint and a bit worse
> compression...
> Example: I have 6000 connections to a proxy, using CompressionFilter between
> proxy and clients. When profiling with JProfiler, I find that 2GB of the heap
> in the proxy is used only by CompressionFilter (ZLib) objects. (!) These
> objects are not GCed until connections close.
> For now I have created a workaround that compresses each message within the
> encoder by using standard java.util.zip compression. But it is bad design,
> since it really is better to perform this using a filter externally from a
> decoder... (?)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
