The following comment has been added to this issue:
Author: Alan Cabrera
Created: Tue, 24 Aug 2004 11:33 AM
Body:
It's not clear to me that there is a problem. First off, each event scheduled
by the SelectorManager handles a specific READ or WRITE events. A READ event
will not perform WRITE processing. Even if it did, the buffers are associated
with the socket, not the event, so that if a READ event did push out data, it
would be in order; when the WRITE event finally executed, it would fall out,
doing nothing.
Maybe I'm missing something. Could you provide a thread trace of the problem?
Regards,
Alan
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/GERONIMO-288?page=comments#action_37437
---------------------------------------------------------------------
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: Tue, 24 Aug 2004 11:33 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
