[
https://issues.apache.org/jira/browse/DIRMINA-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frederic Bregier reopened DIRMINA-279:
--------------------------------------
Hi all,
I recently upgraded to MINA-trunk (2-M1) and this bug reappears
(compression returns (-5) in exception as described before).
Probably the fix in 1.1 was not redo in 2-M1 ?
WDYT ?
Frederic
> CompressionFilter returns error -5 (Z_BUF_ERROR) from jzlib in MINA 1.0 but
> not in MINA 0.9.4
> ---------------------------------------------------------------------------------------------
>
> Key: DIRMINA-279
> URL: https://issues.apache.org/jira/browse/DIRMINA-279
> Project: MINA
> Issue Type: Bug
> Components: Core, Filter
> Affects Versions: 2.0.0-M1
> Environment: Windows XP JDK 1.5.0.6 SUN With and Without Backport
> Reporter: Frederic Bregier
> Assigned To: Trustin Lee
> Fix For: 1.0.1
>
> Attachments: test.zip
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
