[
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.
