The following comment has been added to this issue: Author: Bulent Erdemir Created: Wed, 25 Aug 2004 12:37 AM Body: I was reading through the code and it seemed to me that there might be unordered messages. I don't have an exact evidence. In fact, that's why I used *might* while reporting the problem. Therefore, let's close this issue until I find a provable test case which is not very likely to happen based on your comment of 'buffers are associated with sockets, not with events'.
Regards, Bulent Erdemir --------------------------------------------------------------------- View this comment: http://issues.apache.org/jira/browse/GERONIMO-288?page=comments#action_37442 --------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/GERONIMO-288 Here is an overview of the issue: --------------------------------------------------------------------- Key: GERONIMO-288 Summary: NIO Network code might send unordered messages Type: Bug Status: Open Priority: Major Project: Apache Geronimo Components: core Assignee: Alan Cabrera Reporter: Bulent Erdemir Created: Tue, 24 Aug 2004 8:15 AM Updated: Wed, 25 Aug 2004 12:37 AM Description: Hi, Geronimo network code might deliver messages out of order. To be more specific, the network code tries to write a buffer and if remaining()>0, registers an OP_WRITE interest in order to drain the buffer contents later (when the channel is available for write). When the server is loaded, things can get hairy and we might receive another write event which might get scheduled to run before the OP_WRITE is processed. More specifically, SocketProtocol.serviceWrite reads: long count = socketChannel.write(sendBuffer); log.trace("Wrote " + count); if (sendBuffer[i].hasRemaining()) { // not all was delivered in this call setup selector // so we setup to finish sending async. log.trace("+OP_WRITE " + selectionKey); selectorManager.addInterestOps(selectionKey, SelectionKey.OP_WRITE); return; } Since there's no synchronization, in a situation where the selector returns with OP_WRITE (in SelectorManager) but not yet finds the chance to process the event, another thread loaded with a read event might sneak in and call the above lines, the result of which would be sending data out of order. Regards, Bulent Erdemir --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira