[
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 <[EMAIL PROTECTED]> 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.
