Re: Change in behaviour of CompressionFilter

[Emmanuel Lécharny]

Hi Greg, Jonathan,

it was 3 years ago, and I don't remember what was the root cause of this 
change. However, reading the diff, what I can tell is that the changed 
version assume that the original message (ie the message the app is 
writing) may not be a IoBuffer, and in this case, we needed to process 
it differently.


Let me clarify.

When a message is written by an application, it can be anything ( a 
String, a data structure, some byte[], whatever), but it means something 
for the application. Then it goes through the filter chain, and it get 
encoded, encrypted, compressed, it all depends on the filters in use. 
When it hits the bottom of the chain, it's a IoBuffer that has to be 
written to the remote peer. When this IoBuffer has been fully written, 
we can send the MessageSend event back to the IoHandler, and we do so by 
using the 'original' message (ie the message before it get 
encoded/compressed/encrypted) to avoid having to 
decode/decrypt/decompress it again. It's like :


IoHandler write( <original message> ) -> [filter] --(origMsg, 
transformedMsg)--> [filter] --(origMsg, transformedMsg)--> 
...--(origMsg, transformedMsg)--> [Head]-> write transformed data to socket

when the data has been fully sent, we go back :

[Head] --(origMsg)--> [filter] --> ... --(origMsg)--> IoHandler "The 
<origMsg> message has been fully sent"

This original message is likely not to be contained in a IoBuffer, so we 
have to keep it as is. OTOH,  if it was a IoBuffer, its position has 
changed while being processed in the filter chain, as ity has been read, 
so we need to reset its position to the very beginning.


Anyway, looking at the exception you get, here is what I suspect : the 
buffer has been flipped, or cleared, and the mark is now -1, which leads 
to the message you get when trying top do a reset on it.


Is there a way to see the code that get called when you get this error ?

On 19/03/2019 18:18, Greg Thomas wrote:
Details from
https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=44b58469f84ce991074cdc187b1c1f23b94cf445

Don't try to reset a message when it's not a IoBuffer

Emmanuel Lécharny <elecha...@symas.com>

Tue, 16 Feb 2016 14:38:14 +0000 (15:38 +0100)

Greg

On Tue, 19 Mar 2019 at 17:17, Jonathan Valliere <jon.valli...@emoten.com>
wrote:

I’m trying to look it up in gitbox and it doesn’t show the ids. What was
the date / first few words of commit message?

On Tue, Mar 19, 2019 at 1:13 PM Greg Thomas <greg.d.tho...@gmail.com>
wrote:

So just to clarify;

If we run against 2.0.14, connections using the CompressionFilter fail.

If I ...

$ git clone http://gitbox.apache.org/repos/asf/mina.git mina
$ cd mina
$ git checkout 2.0.14
$ git revert 44b58469f84ce991074cdc187b1c1f23b94cf445
$ mvn clean package

and use the JAR files from that, connections using the CompressionFilter
succeed.

So I'm pretty confident that commit
44b58469f84ce991074cdc187b1c1f23b94cf445 is the culprit. I just don't
understand the code well enough to be able to suggest why/how to fix it.

Greg


On Tue, 19 Mar 2019 at 14:39, Jonathan Valliere <john...@apache.org>
wrote:

Have you pulled a diff between 13 and 14 to try to narrow it down?
It’s
always possible that there is a concurrency problem with compression
filter
which is now exposed through other changes... like what we have with
SSL.
On Tue, Mar 19, 2019 at 8:33 AM Greg Thomas <greg.d.tho...@gmail.com>
wrote:

Openfire - an XMPP server,
https://www.igniterealtime.org/projects/openfire/index.jsp - makes
heavy
use of Apache MINA for it's I/O.

One of the things it uses is the CompressionFilter - if clients
enable
the
Compression XMPP option.

We've recently updated to a newer version of MINA, and with no other
code
changes found that enabling compression (in XMPP clients) fails. I've
narrowed it down to changes between MINA 2.0.13 (where it works) and
2.0.14
through to 2.1.0 (where it doesn't) - with Openfire throwing the
following
stack trace:

java.nio.InvalidMarkException: null
at java.nio.Buffer.reset(Buffer.java:306) ~[?:1.8.0_162]
at


org.apache.mina.core.buffer.AbstractIoBuffer.reset(AbstractIoBuffer.java:424)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.core.polling.AbstractPollingIoProcessor.writeBuffer(AbstractPollingIoProcessor.java:940)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.core.polling.AbstractPollingIoProcessor.flushNow(AbstractPollingIoProcessor.java:840)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.core.polling.AbstractPollingIoProcessor.flush(AbstractPollingIoProcessor.java:767)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.core.polling.AbstractPollingIoProcessor.access$700(AbstractPollingIoProcessor.java:68)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1125)
~[mina-core-2.0.14.jar:?]
at


org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
~[mina-core-2.0.14.jar:?]
at


java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_162]
at


java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_162]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]

Narrowing down even further the commit at


https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=44b58469f84ce991074cdc187b1c1f23b94cf445
seems
to be the culprit.

At this point, I'm drawing a blank.

It's possible Openfire is using the CompressionFilter wrongly, which
was
being masked until the above commit.

It's possible the above commit doesn't do what was intended, but I
don't
pretend to understand what it is/should be doing.

It's possible I've got the wrong end of the stick, and it's something
else
between MINA 2.0.13 and 2.0.14 that changed that is causing the
problem.
But at this point, I don't know where to start, so would appreciate
any
pointers!

Thanks,

Greg

--

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.