[ 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.