You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2019/05/04 22:10:00 UTC
[jira] [Resolved] (DIRMINA-1101) InvalidMarkException on
session.write when using CompressionFilter.
[ https://issues.apache.org/jira/browse/DIRMINA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRMINA-1101.
----------------------------------------
Resolution: Fixed
Fix Version/s: 2.1.2
Fixed for 2.1 branch. Still a problem in. 2.0, but it won't be fixed.
> InvalidMarkException on session.write when using CompressionFilter.
> -------------------------------------------------------------------
>
> Key: DIRMINA-1101
> URL: https://issues.apache.org/jira/browse/DIRMINA-1101
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.20
> Reporter: Jörg Michelberger
> Assignee: Emmanuel Lecharny
> Priority: Major
> Fix For: 2.1.2
>
>
> I'm updated from a MINA 2.0.7 to the 2.0.20 and am a user of CompressionFilter. Writing of Messages fails with a InvalidMarkException.
> Reproducible Test is:
> * Copy MINA Core Test org.apache.mina.core.service.AbstractIoServiceTest to MINA Compression Filter org.apache.mina.filter.compression Test Packages package.
> * Adapt package statement to org.apache.mina.filter.compression.
> * Add Compression to acceptor and connector
> * acceptor.getFilterChain().addLast("compression", new CompressionFilter());
> acceptor.getFilterChain().addLast("logger", new LoggingFilter());
> acceptor.getFilterChain().addLast("codec",
> new ProtocolCodecFilter(new TextLineCodecFactory(StandardCharsets.UTF_8)));
> * connector.getFilterChain().addLast("compression", new CompressionFilter());
> connector.getFilterChain().addLast("logger", new LoggingFilter());
> connector.getFilterChain().addLast("codec",
> new ProtocolCodecFilter(new TextLineCodecFactory(StandardCharsets.UTF_8)));
> * Set a Breakpoint to java.nio.Buffer.reset() method, where the InvalidMarkException is thrown.
> * Run Debug Testfile on org.apache.mina.filter.compression.AbstractIoServiceTest
> After the Exception the session is immediatelly scheduled for disconnect.
> It seems that there is a discrepancy between the mark() and reset() calls on the underlaying Buffer. In case of compression, a Buffer with the compressed content is created and is wrapped with the original Buffer in a FilteredWriteRequest, because CompressionFilter is a WriteRequestFilter. This is in WriteRequestFilter.filterWrite()
> In DefaultIoFilterChain$HeadFilter.filterWrite() is then the mark() call, which is done on the compressed Buffer.
> In AbstractPollingIoProcessor.writeBuffer() is the reset() call, which is in this case done on the original Buffer, leading to the Exception.
> It seems that the change at date 16.02.2016
> SHA-1: 44b58469f84ce991074cdc187b1c1f23b94cf445
> * Don't try to reset a message when it's not a IoBuffer
> which reassignes the buf before reset() is called broke it. The buf before reassign looks much better as the right to reset() in this case.
>
> {{java.nio.InvalidMarkException}}
> {{ at java.nio.Buffer.reset(Buffer.java:306)}}
> {{ at org.apache.mina.core.buffer.AbstractIoBuffer.reset(AbstractIoBuffer.java:425)}}
> {{ at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1131)}}
> {{ at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)}}
> {{ at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)}}
> {{ at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)}}
> {{ at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)}}
> {{ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)}}
> {{ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)}}
> {{ at java.lang.Thread.run(Thread.java:748)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)