On 4/4/07, Sebastiaan van Erk <[EMAIL PROTECTED]> 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. 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]
