CompressionFilter returns error -5 (Z_BUF_ERROR) from jzlib in MINA 1.0 but not in MINA 0.9.4

• Key: DIRMINA-279
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Trustin Lee
• Reporter: Frederic Bregier
• Component/s: Core, Filter
• Affects Version/s: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0
• Fix Version/s: 1.0.4, 1.1.1

Description

I found an issue in MINA 1.0 that was not present in MINA 0.9.4 with the compression filter.
I was able to reproduced the problem in small example that I will attach.
The example use both compression and serialization from MINA filters.
The example has two kind of servers : one using demuxingIoHandler and another one without such an IoHandler (simpler).
The example was inspired from the SumUp example. This one should also bug but it was not detected
since the SumUp example was not printing any error while an exception occurs.
The exception is the following, both on the client and server :

java.io.IOException: Compression failed with return value : -5
at org.apache.mina.filter.support.Zlib.deflate(Zlib.java:181)
at org.apache.mina.filter.CompressionFilter.filterWrite(CompressionFilter.java:198)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:789)
at org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:221)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:789)
at org.apache.mina.common.support.AbstractIoFilterChain$2.filterWrite(AbstractIoFilterChain.java:213)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:573)
at org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIoFilterChain.java:564)
at org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketSessionImpl.java:186)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:146)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:132)
at test.ClientSessionHandler.sessionOpened(ClientSessionHandler.java:30)
at org.apache.mina.common.support.AbstractIoFilterChain$2.sessionOpened(AbstractIoFilterChain.java:156)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:431)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:752)
at org.apache.mina.common.IoFilterAdapter.sessionOpened(IoFilterAdapter.java:63)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:431)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:752)
at org.apache.mina.common.IoFilterAdapter.sessionOpened(IoFilterAdapter.java:63)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:431)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:752)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:261)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)

I have one idea for the reason of the bug but I am not sure since I am not an expert on jzlib usage :
In Mina 0.9.4, the threadpool was inside Mina using its own way.
In Mina 1.0, the threadpool is using backport (or native JDK 1.5 if change are made in Mina code).
(both case are in bugs, with and without backport)
Perhaps the reason of the bug could be any persistent data needed by jzlib in order to compressed
that are not persistent in Mina 1.0.
However, the bug is relative both to the server and the client (which is not supposed to use any thread pool).
And the bug is immediate with only one client making only one connection and from the first write.
So it should not be this way.

Frederic