[jira] Resolved: (DIRMINA-367) 1.1 proxy example broken with svn revision: 522721

["Trustin Lee (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee resolved DIRMINA-367.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0-M1
         Assignee: Trustin Lee

MINA 2.0.0-M1-SNAPSHOT now provides closeOnFlush() method, so you don't need to call join() compromising performance anymore.  closeOnFlush() method closes the connection after all queued write requests are flushed out.

> 1.1 proxy example broken with svn revision: 522721
> --------------------------------------------------
>
>                 Key: DIRMINA-367
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-367
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>         Environment: linux
>            Reporter: keith mcneill
>            Assignee: Trustin Lee
>             Fix For: 2.0.0-M1
>
>
> I just updated to the latest version of mina and my server app broke.  It is partially based on the proxy example.  Looking back through the svn logs, things seem to break on r522721.   I've confirmed this with the stock proxy example.
> The proxy sometimes closes sessions without writing results to the client.  Client gets back zero bytes.   My clients have lots of HTTP like calls....quick in and out exchanges with the server.  
> The line in question is in: core/src/main/java/org/apache/mina/transport/socket/nio/SocketIoProcessor.java
> in the doFlush() method the added line from that svn revision is:
> if( key.isWritable() )   ~ line 426
> breaks things.  If I comment it out, things work fine.  
> Looking more closely at the code I don't quite understand how the method is supposed to work.  My nio knowledge is somewhat limited but.  
> When the method is entered we do the following:
> // Clear OP_WRITE
>         SelectionKey key = session.getSelectionKey();
>         key.interestOps( key.interestOps() & ( ~SelectionKey.OP_WRITE ) );
> We clear OP_WRITE.
> then in the for loop we do the:
> if( key.isWritable() ) 
> test.
> How is it ever supposed to report back as writable if we clear OP_WRITE.  Does it work sometimes now because of a race condition with further writes on the socket?

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