You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "keith mcneill (JIRA)" <ji...@apache.org> on 2007/04/10 20:52:32 UTC
[jira] Created: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
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
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.
[jira] Resolved: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
Posted by "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.
[jira] Commented: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
Posted by "keith mcneill (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488132 ]
keith mcneill commented on DIRMINA-367:
---------------------------------------
Thanks. I think you are right on the money. There is a race condition
in the sessionClosed() call and any pending writes. What is the best
way to ensure the data is written? In messageReceived() I could get a
WriteFuture from the write() call and join on the write? Will that
inhibit concurrency within the server? Is there a better way?
Thanks!
Keith
> 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
>
> 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.
[jira] Closed: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRMINA-367.
-------------------------------------
> 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.
[jira] Commented: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488000 ]
Trustin Lee commented on DIRMINA-367:
-------------------------------------
The additional check is added to fix DIRMINA-362. isWritable() ans isReadable() is related with readyOps rather than with interestOps, so removing the flag from interestOps won't change the return value of isWritable().
I think there's possibility that data is not written when the connection is closed from the server. In the proxy example, the client connection is closed immediately if the server connection is closed. Any write requests not yet flushed out to the channel can be swallowed. Instead of closing the client connection immediately after the server closes the connection, you could make sure all data received from server is forwarded to the client thoroughly.
You could also provide a stripped down version of your code that reproduces the problem so I can test it.
> 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
>
> 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.
[jira] Commented: (DIRMINA-367) 1.1 proxy example broken with svn
revision: 522721
Posted by "keith mcneill (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489581 ]
keith mcneill commented on DIRMINA-367:
---------------------------------------
I'm just now getting a chance to check performance of my proxy server.
With the fix from r522721 and doing a WriteFuture.join() in messageReceived peformance isn't so good compared to the non-proxy version. If I undo the fix from r522721 and don't do the join in messageRecieved() then performance is better. Is there a better way to avoid the race condition rather than doing the join in messageRecieved()? Is there some way to instead wait in close until all of the writes are flushed? Though that seems like it would tricky with race conditions also.
Thanks!
Keith
> 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
>
> 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.