[mina] Bug in SocketIoProcessor.flush()

[Niklas Therning <ni...@trillian.se>]

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;
  }
  ...
}

I hope this made any sense! :) BTW: Should I have submitted this
directly to JIRA? Or do I need an account for that?
/Niklas

Re: [mina] Bug in SocketIoProcessor.flush()

[Trustin Lee <tr...@gmail.com>]

Hi Niklas,

Thank you for reporting this bug. I put this issue into the JIRA:

http://issues.apache.org/jira/browse/DIRMINA-110

and I checked in the fix already.

Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/