tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rémy Maucherat" <>
Subject Re: Another Comet 6.0.10 question
Date Wed, 04 Apr 2007 21:51:01 GMT
On 4/4/07, Sebastiaan van Erk <> wrote:
> 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).

I didn't think you were using Windows, so I didn't mention it: the
problem is that Windows notifies disconnects as a regular read event,
rather than with an error code. In that case, you have to do an
additional read to get the IO exception, after which the connection is
closed. If you don't read (and either let the exception go through or
close the event), the socket goes back to the poller, and is signaled
again right away. That's totally annoying ... It should work properly
in Unix, but you'll get an error event, and that will be the end of
your connection.

> 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 I said, I don't know what the problem is. I am interested in fixing
identified bugs, and trying to improve on behaviors where I can.

> 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.

Evidently, HTTP has never been designed as a protocol where the client
and the server would use it as a convinient way to open a
biderectional communication channel. As a result, this usage can have
unspecified compatibility issues, not scale with proxy X or Y, etc.
Note however that the HTTP protocol is still respected, as long as you
use chunking for all transfers.

The main point in Tomcat was to provide an easy API which would blend
with the servlet API and could meet certain specific needs, until
something better emerges (and it's not going to be an async HTTP
Servlet API, since it would have the same exact compatibility issues).

> The reason I keep asking about this

does not make much sense. It's possible there will be refinements to
the behavior eventually, but there's nothing which requires you to
send an EOF on input. You want to do it, but it's really your design
choice and has no real benefit.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message