All tests are now passing green with my last commit in the write request
branch.
Feel free to have a look at it.
On 25/03/2019 19:12, Emmanuel Lécharny wrote:
Ok, I know what's the cause of this failure.
What happens when we process the handshake is that the SslFilter
exchange some
Ok, I know what's the cause of this failure.
What happens when we process the handshake is that the SslFilter
exchange some messages with the remote peer. Those messages have no
reason to be transmitted to the application though the messageSent
event, so teh SslFilter must swallow this event
And here are the SSL debug traces :
...
0update handshake state: change_cipher_spec
0upcoming handshake states: server finished[20]
10: 01 00 D5 D2 05 1B C0 51 13 A6 40 EC 80 9F 2A 4C ...Q..@...*L
0020: EC D3 BF 1A 5B 4C 57 87 E3 D9 0B 35 2F 32 20 64 [LW5/2 d
0030: DE 93 74 81
FTR, I have all the test passwing with my committed changes, but one :
SslFilterTest.testMessageSentIsCalled_With_SSL. I get this stack trace :
`
javax.net.ssl.SSLException: bad record MAC
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at
On 25/03/2019 02:10, Jonathan Valliere wrote:
I’m going to look at this starting Tuesday. Emmanuel do you mind creating
a branch for this Jira issue so I can track what you’re working on?
The branch name is 'mina-write-request'. It's from MINA 2.1.
On 25/03/2019 02:10, Jonathan Valliere wrote:
I’m going to look at this starting Tuesday. Emmanuel do you mind creating
a branch for this Jira issue so I can track what you’re working on?
Sure
I’m going to look at this starting Tuesday. Emmanuel do you mind creating
a branch for this Jira issue so I can track what you’re working on?
On Sun, Mar 24, 2019 at 3:54 AM Emmanuel Lécharny
wrote:
> Things are complicated :/
>
> Ok, after two days of investigation, my take is that the
Things are complicated :/
Ok, after two days of investigation, my take is that the original sin
was to use a IoBuffer to propagate a message across the filters.
IoBuffers can be consumed (ie, when you read them, their position
change) making it very complex not to abuse them when writing a
Ok, I have a version that works better with the CompressionFilter.
Here is what I have changed :
- the session.write( ) method will inject the original message
into the WriteRequest
- any filterWrite filter that is going to create a new version of the
message will store it in the same
Hmmpp
I have traced the calls when a session.write( ) is done.
It's all a kind of a hack.
In order to be able to send the messageSent() event, the protocolFilter
will call the nextFilter.filterWrite() method twice :
public void filterWrite(NextFilter nextFilter, IoSession
On 20/03/2019 16:13, Jonathan Valliere wrote:
I’ll look into not using mark reset there.
I agree that using mark and reset is a kind of a non sense. Let's go
back to the original requirement :
- when we call a session.write(message), we know the message will go
through multiple filters
I’ll look into not using mark reset there.
On Wed, Mar 20, 2019 at 11:05 AM Emmanuel Lécharny
wrote:
>
> On 20/03/2019 15:30, Jonathan Valliere wrote:
> > The offending code is in AbstractPollingIoProcessor. Are you agreeing
> that
> > AbstractPollingIoProcessor has no place modifying the
On 20/03/2019 15:30, Jonathan Valliere wrote:
The offending code is in AbstractPollingIoProcessor. Are you agreeing that
AbstractPollingIoProcessor has no place modifying the buffer positions?
Removing buf.reset() would probably fix the problem.
The reason we reset the buffer is that we
And all use of mark() should be removed through the entire codebase... but
thats a second step.
On Wed, Mar 20, 2019 at 10:30 AM Jonathan Valliere
wrote:
> The offending code is in AbstractPollingIoProcessor. Are you agreeing
> that AbstractPollingIoProcessor has no place modifying the buffer
The offending code is in AbstractPollingIoProcessor. Are you agreeing that
AbstractPollingIoProcessor has no place modifying the buffer positions?
Removing buf.reset() would probably fix the problem.
(replying to the mailing list)
On 20/03/2019 15:11, Jonathan Valliere wrote:
And mina is calling reset() bad combo. Why would mina ever need to
modify the position? Just keep on writing the buffer as-is until flushed?
It should. Any filter taking a IoBuffer as an input should *never*
Nothing in Mina should use the mark/reset functionality because it does not
compound and the unknown addition of filters create edge cases where it is
compounded. Should manually grab he position and manually revert the
position when necessary.
On Wed, Mar 20, 2019 at 4:23 AM Greg Thomas wrote:
Many thanks!
Greg
> On 20 Mar 2019, at 07:42, Emmanuel Lécharny wrote:
>
> I can reproduce the issue with a much simpler application (using the 'chat'
> example).
>
> I will try to get a fix asap.
>
>
>> On 19/03/2019 23:33, Emmanuel Lécharny wrote:
>> Ok, looking at the CompressionFilter,
I can reproduce the issue with a much simpler application (using the
'chat' example).
I will try to get a fix asap.
On 19/03/2019 23:33, Emmanuel Lécharny wrote:
Ok, looking at the CompressionFilter, here is what I see:
@Override
protected Object doFilterWrite(NextFilter
Ok, looking at the CompressionFilter, here is what I see:
@Override
protected Object doFilterWrite(NextFilter nextFilter, IoSession
session, WriteRequest writeRequest)
throws IOException {
...
IoBuffer inBuffer = (IoBuffer) writeRequest.getMessage();
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
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
Tue, 16 Feb 2016 14:38:14 + (15:38 +0100)
Greg
On Tue, 19 Mar 2019 at 17:17, Jonathan Valliere
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 wrote:
> So just to clarify;
>
> If we run against 2.0.14, connections using the CompressionFilter fail.
>
> If I ...
>
> $ git
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
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 wrote:
> Openfire - an XMPP
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
26 matches
Mail list logo
