You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mina.apache.org by bu...@apache.org on 2019/04/08 15:53:06 UTC

svn commit: r1043359 - in /websites/staging/mina/trunk/content: ./ mina-project/userguide/ch5-filters/ch5.3-compression-filter.html

Author: buildbot
Date: Mon Apr  8 15:53:06 2019
New Revision: 1043359

Log:
Staging update by buildbot for mina

Modified:
    websites/staging/mina/trunk/content/   (props changed)
    websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html

Propchange: websites/staging/mina/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Apr  8 15:53:06 2019
@@ -1 +1 @@
-1856950
+1857118

Modified: websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html
==============================================================================
--- websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html (original)
+++ websites/staging/mina/trunk/content/mina-project/userguide/ch5-filters/ch5.3-compression-filter.html Mon Apr  8 15:53:06 2019
@@ -186,7 +186,25 @@ h2:hover > .headerlink, h3:hover > .head
 }
 h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
 <h1 id="53-compression-filter">5.3 - Compression Filter<a class="headerlink" href="#53-compression-filter" title="Permanent link">&para;</a></h1>
-<p>TBD...</p>
+<p>The <em>CompressionFilter</em> class is used to compress data before it gets sent and decompress it when it's received. It uses the <a href="http://www.jcraft.com/jzlib/">JZLIB library</a>.</p>
+<p>It only handles two events :</p>
+<ul>
+<li><em>messageReceived</em>: The received message will be decompressed, if it's contained in a <em>IoBuffer</em>.</li>
+<li><em>filterWrite</em>: The message to write will be compressed, assuming it's storeed in a <em>IoBuffer</em> (otherwise an exception will be generated).</li>
+</ul>
+<h2 id="configuration">Configuration<a class="headerlink" href="#configuration" title="Permanent link">&para;</a></h2>
+<p>It's possible to configure the <em>CompressionFilter</em>, with the listed parameters :</p>
+<ul>
+<li><em>compressInbound</em>: if set to <em>true</em>, the incoming data will be decompressed, otherwise they will be left intact.</li>
+<li><em>compressOutbound</em>: if set to <em>true</em>, the outgoing data will be compressed, otherwise they will be ignored.</li>
+<li><em>compressionLevel</em>: one of <em>COMPRESSION_DEFAULT</em> (-1), <em>COMPRESSION_MAX</em> (9), <em>COMPRESSION_MIN</em> (1), <em>COMPRESSION_NONE</em> (0). Sets the level, of desired compression.</li>
+</ul>
+<p>There is one more parameter that can be used, injected into the session's attributes, the <em>DISABLE_COMPRESSION_ONCE</em> flag. If present in the session's attributes, the first compression will be ignored (this is probably useful for application that needs to send a message that the floowing messages are going to be compressed).</p>
+<h2 id="initialization">Initialization<a class="headerlink" href="#initialization" title="Permanent link">&para;</a></h2>
+<p>When the filter is added to the chain, instances of the deflater and inflater are created and injected into the session's attributes. This could change, as each session has its own instance of the filter in its chain, so there is no reason not to store those instances in the filter itself.</p>
+<h2 id="side-notes">Side notes<a class="headerlink" href="#side-notes" title="Permanent link">&para;</a></h2>
+<p>The way this filter works does not lmake it very efficient. It requires that the received data to be decompressed are fully read - and there are no control that it's the case of not -, and it also requires that the data to be compressed be fully compressed in one pass, which is quite inneficient from the memory perspective, as we may compress data by blocks, and send them immediately, waiting for the block to be really sent to compress the next one.</p>
+<p>All in all, it's a brittle filter, you'd better not use it !</p>
 
 
     <div class="nav">