Let's add this to today's Project Grizzly Meeting agenda.
Scott, you don't have to join. Since CORBA uses a multiplexed protocol,
there will be several of us in this meeting who understand what you are
saying in the filed issue.
charlie ...
-------- Original Message --------
Subject: [Issue 38] New - OutputWriter can't handle multiple writers
Date: Wed, 31 Oct 2007 14:57:31 +0000
From: sdo_at_dev.java.net
Reply-To: issues_at_grizzly.dev.java.net
To: issues_at_grizzly.dev.java.net
https://grizzly.dev.java.net/issues/show_bug.cgi?id=38
Issue #|38
Summary|OutputWriter can't handle multiple writers
Component|grizzly
Version|1.5.2
Platform|All
OS/Version|All
URL|
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P3
Subcomponent|framework
Assigned to|issues_at_grizzly
Reported by|sdo
------- Additional comments from sdo_at_dev.java.net Wed Oct 31 14:57:26 +0000 2007 -------
The OutputWriter class is intended to wait up to 1 minute (default wait time)
for output space to be available to complete writing the data. In an HTTP mode
(or for similar protocols), that works just fine.
For protocols (like SIP) where multiple threads are writing to the same socket,
buffer contention will cause OutputWriter to report an error prematurely. Say
there are 10 threads writing on the socket that fills up; all 10 will get a
selector and enter the select() call. When the socket buffer empties, all 10
will get notified that they can write data, and all will attempt to write their
data -- but while the socket is still draining, it's likely that only 1 will
succeed and the remaining will write 0 bytes again. If this process is repeated
twice, the remaining sockets will give up (based on the attempts value in
OutputWriter) and close the socket. This entire process takes only a few
milliseconds, since during that time there will be two successful writes.
The async queueing model should take this into account, or we should develop a
selector-per-socket model such that only one thread can wake up from the select
at a time.
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: issues-help_at_grizzly.dev.java.net
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>