Hmm,
good point, but the HTTP/1.1 Spec RFC2616 (chapter 8.1, 14.10) not
describe that server must
close the connection as header Connection: close is set. This means
that tomcat currently wait for socket timeout
before connection is close.
I have analyse the tomcat 6 trunk and see that we
Hi,
The request, wait, async response + close pattern seems to be a
pretty common use case though, especially with server side push
(AJAX), so it would still be good to have a solution that works well
allways.
Yes, and for this you don't need Comet, you need Asynchronous
Servlets they are
On 4/28/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Hi,
The request, wait, async response + close pattern seems to be a
pretty common use case though, especially with server side push
(AJAX), so it would still be good to have a solution that works well
allways.
Yes, and for this you
Hi,
I've been thinking about this a bit more, and I understand why normally
the response.close() should not go to the TCP layer: I'd forgotten all
about request pipelining.
However, in my case, the request has an explicit Connection: close header.
Would not this case warrent an immediate
Sebastiaan van Erk wrote:
Rémy Maucherat wrote:
On 4/26/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
I don't understand why the client does not get an immediate -1 (EOF) on
the read() as soon as I do this. The socket itself does not need to be
closed, but the output stream close should
Hi,
* Is it possible, somehow, to end a request asynchronously (that is,
outside the event method)?
Because I keep getting Out of file descriptor errors since the END
events come so terribly late after I do the close().
you'd still get too many open files errors even if it did close
since
Sebastiaan van Erk wrote:
Hi,
* Is it possible, somehow, to end a request asynchronously (that is,
outside the event method)?
Because I keep getting Out of file descriptor errors since the END
events come so terribly late after I do the close().
you'd still get too many open files errors
I see the same problem with my client too. However, I don't see the
issue when I use a client using Jakarta HTTP client. I'm still looking
into this. Any help will, of course be welcome and delightfully
devoured.
This is not really the same bug report, but something to think about
when you're
Hi,
The reason I get the exceptions on the Tomcat server side seems to be
because I close the socket on the client at the same time I try to close
it on the server, causing two unsynchronized closes on the OutputStream.
I don't really know what to synchronize on though, since I don't have an
Correct, an asynchronous close doesn't go all the way down to the IO
layer, it just marks the request closed.
remember event.close doesn't mean TCP.socket.close, it means that this
event/request sequence is done
There are still many enhancements to be done to the Comet API, such as
non
Hi,
Sorry about the essays. :-) I will try to keep it shorter.
What I'm doing is closing the *output stream* of the response from the
server side application asynchronously.
Since this is outside the event() method, I do not have any reference to
a CometEvent instance.
I don't understand
On 4/26/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
I don't understand why the client does not get an immediate -1 (EOF) on
the read() as soon as I do this. The socket itself does not need to be
closed, but the output stream close should flush the output stream and
call shutdownOutput() on
Rémy Maucherat wrote:
On 4/26/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
I don't understand why the client does not get an immediate -1 (EOF) on
the read() as soon as I do this. The socket itself does not need to be
closed, but the output stream close should flush the output stream and
13 matches
Mail list logo
