Channel writes being made without OP_WRITE selector ready
---------------------------------------------------------

                 Key: DIRMINA-362
                 URL: https://issues.apache.org/jira/browse/DIRMINA-362
             Project: MINA
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.2, 1.0.1, 1.0.0
         Environment: Windows 2000, JDK 1.4+, JBoss 4.0.4GA
            Reporter: Michael Kearns


We've been experiencing 100%CPU Kernel locks when utilising the Mitosis 
directory replication within Apache Directory. The error manifests itself 
within the SocketIoProcessor class, with an instantly returning selector, yet 
no selected keys. It would only happen when Directory replication (within our 
JBoss environment) was enabled, against a non-existant client, and suggests a 
concurrency issue.

Although there are several JVM bugs registered in this area, none seemed to be 
the problem at hand, although troubleshooting was somewhat difficult in that 
the problem is not reproducible 'at will'.

After much testing, I found (amongst other issues) that the 
doFlush(SocketSessionImpl session) method would attempt to write data without 
checking the appropriate selector flags. This would initially result in a 
NotYetConnected exception, and then subsequent spinning of the selector.

I can't say with 100% certainty that adding a check in this location fixes the 
problem, but after 72 hours of uptime in my last test, I have yet to experience 
the problem, whereas it would usually occur within the first few hours of 
running.

The snippet below demonstrates the change, with the 'if' test on the key 
writability being th only change, wrapped around the existing write section.

            if (key.isWritable())
            {
                int writtenBytes = ch.write( buf.buf() );
                if( writtenBytes > 0 )
                {
                    session.increaseWrittenBytes( writtenBytes );
                }
            }

So far as I can tell, this code hasn't changed from 1.0.0 upwards, and so the 
patch would need to be apllied to the 1.0.3 and 2.0.x streams. 

I hope this is of help, and the fix can be applied to 1.0.3 as it's quite a 
critical problem from our usage.

Regards,

Michael.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to