Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
That's the easy part: the bytes are kept in the usual socket buffer,
which will be flushed when the connection comes back from the write
poller, just before invoking the write event.
not so easy, if the servlet invokes write again, you have concurrency
issues. first you register the socket for a WRITE event with the
poller, at the same time an async thread tries to write more data.
That doesn't look like much of a problem to me. The user in that case
would be writing in a situation where canWrite is false (since the
data hasn't been written yet), which is an error. To resume writing
stuff after canWrite becomes false, the servlet would have to wait
until it gets the write event.
and that's my issue, no we are adding a "new hidden API", ie, we are
changing the behavior of the old blocking API.
I like that even less than doing a cast to invoke nbWrite on
writer/outputstream.
outputstream.write should always do a blocking write and return only
when all data is written, not be transformed by the canWrite behavior.
if you dont like casting, then simply adding nbRead/nbWrite to the
CometEvent interface solves all problems.
no need for canWrite, as in the scenario where canWrite returns false,
nbWrite returns 0. same behavior. just simpler and more consistent with
Java and it's non blocking features.
Filip
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
