[
https://issues.apache.org/jira/browse/DIRMINA-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Vermillard resolved DIRMINA-641.
---------------------------------------
Resolution: Won't Fix
the whole compression filter is a memory eater, avoid it if you have serious
load
> 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.
