Hi, thanks very much for the replies.
Rémy Maucherat wrote:
On 4/4/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
Ok, so I get a -1 on a read. Now what do I do?
If I just return from the event handler I immediately get another read
:-(. If I close the event I can't do output anymore.
Since there's not going to be any additional data from the client, and
presumably all data on the socket input has been consumed, it would
seem the only "read" event that this could be is a disconnect (which
on Windows is reported as a regular "there's data on the socket").
Feel free to do your homework too, and try to determine what this
event would be about, I can't reproduce everything.
Hmm... I don't work under Windows, I use Ubuntu Linux, but I'll try
figure out why it keeps sending me READ events after the end of stream
was reached; I'll get back to you on that one (I'll see if I can make a
small test program which exhibits the behavior).
Can't it just send me ERROR/TIMEOUT events, just like what would happen
if no READS arrive at all? In that case I can do async output (like in
the Messaging application example). The CoyoteInputStream I called the
read() on should know it reached the end of stream when I called read(),
so why does it cause another READ event immediately even though it
should know there is no more data? Shouldn't it behave in the same way
that it would normally behave after handling a read event and there
being no more data, i.e., do ERROR/TIMOUT events until the event is
closed or new data arrives (which in this case can't happen)?
As I said, it's not going to happen that way. The thing calling the
events is a poller, not the input stream, and they are generated when
something happens on the socket, or if there's leftover data waiting.
As far as the polling is concerned, I think I don't quite understand the
interface just yet. So far, I've seen the following behavior:
BEGIN -> (no data is sent from the client) TIMEOUT (return form the
handler) -> TIMEOUT (return) -> ...
The timeout here is presumably caused by a socket read (with a certain
timeout)? That would explain why it is not trivial to generate timeouts
after the stream is closed.
BEGIN -> (data) READ -> READ -> READ (read, eof, return from handler) ->
READ (read, eof, return from handler) -> ...
The fact that it keeps on calling read could be because I don't throw an
exception or call event.close(). Maybe that's not the correct use of the
Comet interface?
As far as I can see, the CometProcessor interface is designed around the
input stream. As soon as it reaches the end or is closed, you have to do
what output you can and clean up and close the event. Is that correct?
Is it even possible to do output in parts? HTTP is a request/response
protocol and some caches/proxies don't accept any more input once some
output has been committed. With this restriction it would seem that
output in parts is impossible with Comet. After the input stream is
closed, the polling stops and the event method is never called anymore,
providing no means to end the request. The only way of being able to do
output in parts is keeping the request input stream open until all the
output is done.
I see no fundamental problems of implementing the events as I described
before: that Tomcat keeps polling the event handler while the response
has not been ended. Sure, it's not possible to do this using the events
of the poller on the socket, but I think it must be possible to
implement it in a different manner?
The reason I keep asking about this is because I don't see how else
output in parts is ever going to work with the current interface...
Maybe that's not the intention, but it does seem that the sample
messenger application on the Advanced IO page does in fact also use
output in parts... (To implement the messenger app with request/response
type http, I would imagine the client doing one long request to the
Comet server that sends no data and only reads messages pending on the
server, and short post requests containing a message whenever the client
wants to send one).
To summarize: output in parts seems useful, there seem to be no
fundamental barriers in implementing it, and it can even be done using a
request/response cycle that does not read from the request after data is
committed to the response. The only thing I don't understand is how to
achieve this with the current Comet implementation in Tomcat.
Regards,
Sebastiaan
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
