You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Trustin Lee (JIRA)" <ji...@apache.org> on 2007/11/01 14:37:51 UTC
[jira] Created: (DIRMINA-465) Backward incompatibility in exception
handling of ProtocolCodecFilter
Backward incompatibility in exception handling of ProtocolCodecFilter
---------------------------------------------------------------------
Key: DIRMINA-465
URL: https://issues.apache.org/jira/browse/DIRMINA-465
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.4, 1.0.7
Reporter: Trustin Lee
Fix For: 1.0.8, 1.1.5
On 11/1/07, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
> Hi
>
> We are seeing a really odd behaviour after upgrading yesterday to
> 1.1.4 from 1.1.3
>
> Basically if we see an invalid message (we deem it invalid as part of
> our business logic) we just throw an exception and close the ioSession.
> It worked perfectly up to 1.1.3 and is completely buggered in 1.1.4...
> In 1.1.4 we get tons of exception because of the newly introduced
> while loop (while (in.hasRemaining())) in the try {} catch block of
> the ProtocolCodecFilter messageReceived(...)
<snip/>
> I can't see anything related to this change in the changelog and the
> reason why.
>
> This is a major regression considering that if you have a message
> that is 1000 bytes long and the 1st byte is deemed invalid and you
> want to close this ioSession you will get 1000 times the same
> exception that fills up MBs of logs in seconds!!!
>
> Right now we're going back to 1.1.3
First off, I apologize for your inconvenience. I had to be more careful. :-(
The change occurred while I fix DoS bug in TextLineDecoder. The
latest TextLineDecoder now can keep decoding incoming data even if any
broken data is received (i.e. too long line). With the
ProtocolCodecFilter implementation in 1.1.3, it was not able to
continue decoding until any new data is received even if there was
more than one line in the previous buffer. This means, if client is
sending a too long line + a short line, the messageReceived event for
the short line might not be fired. That was why inserted a loop.
I'd better revert the change back in 1.1.5 and 1.0.8, and provide a
way to take care of TextLineDecoder case in 2.0.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-465) Backward incompatibility in exception
handling of ProtocolCodecFilter
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee closed DIRMINA-465.
-------------------------------
Resolution: Fixed
Assignee: Trustin Lee
Reverted back!
> Backward incompatibility in exception handling of ProtocolCodecFilter
> ---------------------------------------------------------------------
>
> Key: DIRMINA-465
> URL: https://issues.apache.org/jira/browse/DIRMINA-465
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 1.0.7, 1.1.4
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 1.0.8, 1.1.5
>
>
> On 11/1/07, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
> > Hi
> >
> > We are seeing a really odd behaviour after upgrading yesterday to
> > 1.1.4 from 1.1.3
> >
> > Basically if we see an invalid message (we deem it invalid as part of
> > our business logic) we just throw an exception and close the ioSession.
> > It worked perfectly up to 1.1.3 and is completely buggered in 1.1.4...
> > In 1.1.4 we get tons of exception because of the newly introduced
> > while loop (while (in.hasRemaining())) in the try {} catch block of
> > the ProtocolCodecFilter messageReceived(...)
> <snip/>
> > I can't see anything related to this change in the changelog and the
> > reason why.
> >
> > This is a major regression considering that if you have a message
> > that is 1000 bytes long and the 1st byte is deemed invalid and you
> > want to close this ioSession you will get 1000 times the same
> > exception that fills up MBs of logs in seconds!!!
> >
> > Right now we're going back to 1.1.3
> First off, I apologize for your inconvenience. I had to be more careful. :-(
> The change occurred while I fix DoS bug in TextLineDecoder. The
> latest TextLineDecoder now can keep decoding incoming data even if any
> broken data is received (i.e. too long line). With the
> ProtocolCodecFilter implementation in 1.1.3, it was not able to
> continue decoding until any new data is received even if there was
> more than one line in the previous buffer. This means, if client is
> sending a too long line + a short line, the messageReceived event for
> the short line might not be fired. That was why inserted a loop.
> I'd better revert the change back in 1.1.5 and 1.0.8, and provide a
> way to take care of TextLineDecoder case in 2.0.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.