directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DIRMINA-110) Exceptions thrown while writing data are not reported.
Date Fri, 28 Oct 2005 14:32:55 GMT
     [ http://issues.apache.org/jira/browse/DIRMINA-110?page=all ]
     
Trustin Lee closed DIRMINA-110:
-------------------------------

    Resolution: Fixed

This issue has been fixed as Niklas suggested.

> Exceptions thrown while writing data are not reported.
> ------------------------------------------------------
>
>          Key: DIRMINA-110
>          URL: http://issues.apache.org/jira/browse/DIRMINA-110
>      Project: Directory MINA
>         Type: Bug
>     Versions: 0.8
>     Reporter: Trustin Lee
>     Assignee: Trustin Lee
>      Fix For: 0.8.1

>
> Niklas Therning wrote:
> Hi,
> While working on the traffic control implementation I stumbled across a rather nasty
bug. When the remote side of a connection has disconnected ch.write() will throw an IOException
in the following piece of code.  What I've found is that the that exception won't be propagated
to the caller (flushSessions()) which has a catch clause for IOException scheduling the session
for removal.
> for (;;)
> {
>  ...
>  try
>  {
>    writtenBytes = ch.write( buf.buf() );
>  }
>  finally
>  {
>    ...
>    if( buf.hasRemaining() )
>    {
>      ...
>      break;
>    }
>    ...
>  }
> }
> The reason why the exception isn't propagated is the break statement in the finally block.
The break causes the thrown IOException to be discarded and the program counter will be positioned
right after the end of the for-loop. Since there are still unwritten bytes OP_WRITE will remain
on and the selector will wake up immediately on the next iteration. The process will be repeated
indefinitely and the CPU will be on 100%.
> This bug has probably never appeared before since OP_READ has always been on. If OP_READ
is on when the remote side disconnects SocketIoProcessor.read() will handle the removal of
the session.
> This could be fixed by removing the try and finally statements around this piece of code
leaving:
> for (;;)
> {
>  ...
>  writtenBytes = ch.write( buf.buf() );
>  ...
>  if( buf.hasRemaining() )
>  {
>    ...
>    break;
>  }
>  ...
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message