Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <466E61CF.1010609@apache.org>
Date: Tue, 12 Jun 2007 11:05:19 +0200
From: Remy Maucherat <remm@apache.org>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Proposed simplification of CometEvent
References: <46681613.4040903@apache.org>
 <466919E6.9040205@hanik.com>	 <46694438.2060809@apache.org>
 <46694E76.6010408@hanik.com>	 <466959C1.8060709@apache.org>
 <46697192.9000703@hanik.com>	 <46698730.5070400@apache.org>
 <466D1089.5060803@hanik.com>	 <466D3CC0.6050506@apache.org>
 <96e4b5230706111147w1d06043ew6b041453139778c@mail.gmail.com>
In-Reply-To: <96e4b5230706111147w1d06043ew6b041453139778c@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Costin Manolache wrote:
> In the sandbox version:
> - sleep() and setTimeout(int) -> why not sleep(int millis) ? I think it's
> confusing to have both and the interactions between them, in
> particular setTimeout is marked optional ? It makes sense to have
> setTimeout() as a general timeout.

setTimeout() is not optional (the javadoc is out of date, sorry), there 
was an agreement on that earlier. Timeout sets the connection timeout, 
which is most likely useful even if there are events. It's quite 
possible sleep could use a timeout argument (I think calling setTimeout 
is more or less mandatory when using sleep, and OTOH calling setTimout 
is not as important otherwise).

> - not sure I understand the use case for isReadable()/isWriteable() - when
> will this be called ? My understanding was that when
> the connection is readable, a callback will be generated with EventType ==
> READ. Also it's very confusing to mix the 'blocking' in the
> isReadable()/isWriteable() - it would be much cleaner to say that the
> connection is always non-blocking, and add a method to switch to blocking
> mode ( then use the regular servlet methods maybe ). Using the ComentEvent
> for both is IMHO dangerous.

Although the read event indicates there's data to read, isReadable 
indicates if it is possible to continue reading.

isWriteable indicates if the last write operation managed to write more 
than 0 bytes. If the last write wrote 0, then isWriteable will return 
false, so the servlet knows it should stop writing on this connection 
for now (since it cannot accept any output at the moment). Later on, the 
servlet will receive a write event, and can resume writing.

It is possible to add a blockingMode flag, but I've looked into it a 
bit, and found out it is not really needed:
- If doing asynchronous writes using a background thread, non blocking 
helps (if somehow a connection blocks, no other connection will get any 
data until the write completes or times out). I don't see how blocking 
mode could be desired in this case, and the servlet should always be 
using isWriteable.
- If doing synchronous writes inside some event (either a read or 
callback event, most likely), then both blocking and non blocking mode 
make sense. Some servlets may prefer to use blocking mode although it 
could be holding a thread for a while (for example if the idea is only 
to delay the response), and some others could choose to be more 
scalable. Since it is possible to detect if the write is done inside a 
Tomcat thread, and since a servlet which wishes to handle incomplete 
writes would be using isWriteable, it is possible to know when we're in 
the situation where the servlet would prefer blocking. In that case, the 
algorithm in the write method of the connector would be: check if the 
last write returned 0, set blocking mode, flush leftover bytes and send 
the additional bytes which are being written, set non blocking mode. 
It's a trick (of course, it is possible to do the same thing for read), 
and the main drawback is that there are extra operations, but they would 
occur only if needed.

> - will sleep() still allow callbacks ( and if not - what will happen with
> them )? What's going to happen with callbacks if callback() is not called ?

Yes, sleep is meant mostly to handle the reply-later design easily. The 
servlet calls sleep(), and is supposed to call callback() 
(asnychronously, most likely) as a result of something. The connection 
will then wake and the servlet will get a callback event. If callback is 
not called, the connection will timeout and the servlet will get its 
timeout event (according to the connector timeout or the one that has 
been configured for the connection).

> In general ( both versions):
> - it would be great to move it from o.a.catalina to org.apache.comet

It's a possibility.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org