You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2007/04/26 10:36:36 UTC
how to close a comet request outside of an event?
Hi,
I the following Comet question; due to a server event (not a comet
event), I want to write some data to a client request and finish the
request. Currently I write the data and then call OutputStream.close()
on the response output stream. This seems to work, except that it takes
a long time before I get an END event for that request. On the client
this causes the EOF to the request input stream to arrive very late.
This is a problem, because both the server and client are handling so
many requests that I run out of file descriptors and get the following
exception (on the server):
Apr 26, 2007 10:28:23 AM org.apache.tomcat.util.net.NioEndpoint$Acceptor run
SEVERE: Socket accept failed
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:145)
at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:1177)
at java.lang.Thread.run(Thread.java:619)
Note: I'm running the client and server on the same machine, but the
client does not get any "Too many open files" exceptions (it does not
get any exceptions at all), so I'm assuming the process limit of tomcat
is reached, suggesting that tomcat is not closing the request sockets
until the END event...
If I close the request on the client side before I get the EOF (-1) in a
read I don't get the Too many open files problem and generally get the
END event immediately on the server side, but I sporadically get
NullPointerExceptions and AsynchronousCloseExceptions and
ClosedChannelExceptions on the server side in the OutputStream.close()
method. I figure the proper method is for the client tp wait for the
server to say "the request is done" (by waiting for the EOF) before
closing thesocket, but how do I make sure it gets closed immediately on
the server side if I'm not in a comet event?
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Martin Perez <mp...@gmail.com>.
On 4/28/07, Sebastiaan van Erk <se...@sebster.com> 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 don't need Comet, you need "Asynchronous
> > Servlets" they are somewhat different, although you can achieve the
> > same through
> > A) Using a regular servlet, and just hold on to the worker thread
> > B) Using a Comet servlet but with a short timeout.
> > In order for you to not timeout if your write is way delayed, then
> > you need to write some bogus data before the timeout happens
> >
> > As of now, we don't have async servlets on the agenda, and we would
> > need to see what it takes to make Comet to behave like it.
> > Filip
> >
> Actually I looked at Jetty's continuations before I looked at Tomcat's
> Comet. That seems to be the async servlet model. The way it works is
> that the server side application can "wake up" the request after which
> the response must be done immediately. This comes down to the
> application causing the "event" method to be called with a specific
> event. Possibly this approach could be used in Tomcat's Comet as well.
>
> The reasons I didn't go for Jetty's continuations are:
> 1) it really is only request + wait + response, specifically
> a) it would not let me process input as it comes in
> b) it would only let me write output once, after that the response must
> be done
As far as I know for my tests Jetty works: request + wait + wait + wait ...
+ response. You can pause the process as many times as you want and
consequently write to the output as many times as you want. I guess probably
you can also read from the request many times (the continuation objects
offers you also the input stream), but I haven´t tested that.
Cheers,
Martin
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
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 somewhat different, although you can achieve the
> same through
> A) Using a regular servlet, and just hold on to the worker thread
> B) Using a Comet servlet but with a short timeout.
> In order for you to not timeout if your write is way delayed, then
> you need to write some bogus data before the timeout happens
>
> As of now, we don't have async servlets on the agenda, and we would
> need to see what it takes to make Comet to behave like it.
> Filip
>
Actually I looked at Jetty's continuations before I looked at Tomcat's
Comet. That seems to be the async servlet model. The way it works is
that the server side application can "wake up" the request after which
the response must be done immediately. This comes down to the
application causing the "event" method to be called with a specific
event. Possibly this approach could be used in Tomcat's Comet as well.
The reasons I didn't go for Jetty's continuations are:
1) it really is only request + wait + response, specifically
a) it would not let me process input as it comes in
b) it would only let me write output once, after that the response must
be done
Tomcat's Comet seems to be the ultimate solution: you can pretty much do
everything you want; especially handling of the input as it comes in,
and writing to the output without having to finish the response. The
only thing it needs to completely satisfy the async servlet model is
that the application can generate a kind of "CLOSE" event.
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 even if it did close
>> since you are subject to the TIME_WAIT timeout anyway.
>> In a servlet, it is not possible to control the underlying TCP
>> connections, I don't think you could do that with regular servlets
>> either.
>> You bring up an interesting point, but it will require some serious
>> thinking to see if this is feasible or usable :)
>>
>> Filip
>
> Thanks for the answer.
>
> I guess TIME_WAIT would be a bit of a problem. Although the client
> would receive the end of stream signal pretty quickly (long before the
> TIME_WAIT) and probably close the socket, causing an immediate READ or
> END event.
>
> Currently I have found the following solution:
> 1) the server sends an asynchronous close signal to the client in the
> form of some data written to the response outputstream
> 2) the client closes the socket immediately when it receives this
> signal (and I've set the SO_LINGER to true with timeout 0 on the
> client sockets).
> 3) the server immediately gets an END event and cleans up
>
> I pass an OutputStream wrapper to my server side application which
> wraps the response output stream and synchronizes on all methods, and
> in the END event I synchronize using the same lock (the wrapper)
> around event.close(). This seems to have eliminated all race
> conditions, NullPointerExceptions, AsyncCloseExceptions, and
> CloseChannelExceptions. This allows me to do the async close and have
> the socket dissappear immediately, solving the out of file descriptor
> problem for me.
>
> This solution obvioulsy only works because I have control over the
> client in my specific situation. In the case that the client is a
> browser, such control is not possible.
>
> 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 somewhat different, although you can achieve the same through
A) Using a regular servlet, and just hold on to the worker thread
B) Using a Comet servlet but with a short timeout.
In order for you to not timeout if your write is way delayed, then
you need to write some bogus data before the timeout happens
As of now, we don't have async servlets on the agenda, and we would need
to see what it takes to make Comet to behave like it.
Filip
>
> Regards,
> Sebastiaan
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
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 you are subject to the TIME_WAIT timeout anyway.
> In a servlet, it is not possible to control the underlying TCP
> connections, I don't think you could do that with regular servlets
> either.
> You bring up an interesting point, but it will require some serious
> thinking to see if this is feasible or usable :)
>
> Filip
Thanks for the answer.
I guess TIME_WAIT would be a bit of a problem. Although the client would
receive the end of stream signal pretty quickly (long before the
TIME_WAIT) and probably close the socket, causing an immediate READ or
END event.
Currently I have found the following solution:
1) the server sends an asynchronous close signal to the client in the
form of some data written to the response outputstream
2) the client closes the socket immediately when it receives this signal
(and I've set the SO_LINGER to true with timeout 0 on the client sockets).
3) the server immediately gets an END event and cleans up
I pass an OutputStream wrapper to my server side application which wraps
the response output stream and synchronizes on all methods, and in the
END event I synchronize using the same lock (the wrapper) around
event.close(). This seems to have eliminated all race conditions,
NullPointerExceptions, AsyncCloseExceptions, and CloseChannelExceptions.
This allows me to do the async close and have the socket dissappear
immediately, solving the out of file descriptor problem for me.
This solution obvioulsy only works because I have control over the
client in my specific situation. In the case that the client is a
browser, such control is not possible.
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.
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Sebastiaan van Erk wrote:
> Rémy Maucherat wrote:
>> On 4/26/07, Sebastiaan van Erk <se...@sebster.com> 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 the underlying socket.
>>
>> No.
>>
>>> At the moment I have no way of asynchronously ending a response.
>>
>> Calling close() on the event or on the output stream ends a response
>> (objects used for processing of the request will be recycled on the
>> next event, however).
>>
>> Rémy
> Allright, but then *please* can you answer the original question that
> started the whole thing.
>
> * 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
you are subject to the TIME_WAIT timeout anyway.
In a servlet, it is not possible to control the underlying TCP
connections, I don't think you could do that with regular servlets either.
You bring up an interesting point, but it will require some serious
thinking to see if this is feasible or usable :)
Filip
>
> Regards,
> Sebastiaan
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
Rémy Maucherat wrote:
> On 4/26/07, Sebastiaan van Erk <se...@sebster.com> 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 the underlying socket.
>
> No.
>
>> At the moment I have no way of asynchronously ending a response.
>
> Calling close() on the event or on the output stream ends a response
> (objects used for processing of the request will be recycled on the
> next event, however).
>
> Rémy
Allright, but then *please* can you answer the original question that
started the whole thing.
* 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().
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Rémy Maucherat <re...@gmail.com>.
On 4/26/07, Sebastiaan van Erk <se...@sebster.com> 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 the underlying socket.
No.
> At the moment I have no way of asynchronously ending a response.
Calling close() on the event or on the output stream ends a response
(objects used for processing of the request will be recycled on the
next event, however).
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
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 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 the underlying socket.
At the moment I have no way of asynchronously ending a response. Is it
the case that there *is* no way to do this with the current API? Or
should I go about it differently?
Regards,
Sebastiaan
Filip Hanik - Dev Lists wrote:
> 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 blocking reads/writes and others, feel free to gather up your
> thoughts in a bulleted type email instead of the essays, they are a
> little hard to read :)
>
> Filip
>
> Sebastiaan van Erk wrote:
>> 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 event (the close is done as a result of a
>> server side event and not a Comet event); the other close is done
>> deep inside of Tomcat. The only thing that the two have in common
>> could be the request itself or the outputstream, but I don't know if
>> Tomcat does any synchronization on these objects.
>>
>> One way to avoid this simultaneous close would seem to be this: my
>> server application calls close on the OutputStream of the response,
>> my client application reads the EOF (-1) and then closes the socket,
>> causing an END event on the server side, in which I do any necessary
>> cleanup actions.
>>
>> The problem is, when I try this approach, it takes my client many
>> seconds (>30) to receive the EOF, instead of getting it immediately.
>> That is why I was wondering what the correct way is to end a
>> request/response outside of a Comet event (as a result of an
>> application event). Even better would be if I could somehow trigger
>> the END event on the server to finish the request and close the
>> socket, so I don't have to rely on the client to play nice.
>>
>> BTW, I'm using the subversion version of tomcat, synched with
>> subversion late yesterday evening.
>>
>> Regards,
>> Sebastiaan
>>
>> Praveen Balaji wrote:
>>> 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 working with events. Also, it may have a clue I'm missing.
>>>
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=42198
>>>
>>> Also, check with the trunk to make sure you're able to reproduce your
>>> defect.
>>>
>>> Praveen
>>>
>>> -----Original Message-----
>>> From: Sebastiaan van Erk [mailto:sebster@sebster.com] Sent:
>>> Thursday, April 26, 2007 2:07 PM
>>> To: Tomcat Users List
>>> Subject: how to close a comet request outside of an event?
>>>
>>> Hi,
>>>
>>> I the following Comet question; due to a server event (not a comet
>>> event), I want to write some data to a client request and finish the
>>> request. Currently I write the data and then call
>>> OutputStream.close() on the response output stream. This seems to
>>> work, except that it takes a long time before I get an END event for
>>> that request. On the client this causes the EOF to the request input
>>> stream to arrive very late. This is a problem, because both the
>>> server and client are handling so many requests that I run out of
>>> file descriptors and get the following exception (on the server):
>>>
>>> Apr 26, 2007 10:28:23 AM
>>> org.apache.tomcat.util.net.NioEndpoint$Acceptor
>>> run
>>> SEVERE: Socket accept failed
>>> java.io.IOException: Too many open files
>>> at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
>>> at
>>> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:1
>>>
>>> 45)
>>> at
>>> org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:117
>>>
>>> 7)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> Note: I'm running the client and server on the same machine, but the
>>> client does not get any "Too many open files" exceptions (it does
>>> not get any exceptions at all), so I'm assuming the process limit of
>>> tomcat is reached, suggesting that tomcat is not closing the request
>>> sockets until the END event...
>>>
>>> If I close the request on the client side before I get the EOF (-1)
>>> in a
>>>
>>> read I don't get the Too many open files problem and generally get
>>> the END event immediately on the server side, but I sporadically get
>>> NullPointerExceptions and AsynchronousCloseExceptions and
>>> ClosedChannelExceptions on the server side in the
>>> OutputStream.close() method. I figure the proper method is for the
>>> client tp wait for the server to say "the request is done" (by
>>> waiting for the EOF) before closing thesocket, but how do I make
>>> sure it gets closed immediately on the server side if I'm not in a
>>> comet event?
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Peter Rossbach <pr...@objektpark.de>.
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 only made
spezial handling to set Content-Type and Content-Lenght.
(Repsonse.checkSpecialHeader(String,String)
At Http11Processor it is easly to add the connection close feature,
but at NIO and APR it seems complicate.
Peter
Am 27.04.2007 um 08:24 schrieb Sebastiaan van Erk:
> 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 shutdownOutput on the
> underlying socket?
>
> Regards,
> Sebastiaan
>
> P.S.: I really like Tomcat and Comet, so definately good job to you
> guys! Please don't read my emails as complaints; I just want to
> understand the API better and work with you guys to improve Comet
> by reporting possible bugs and sharing the issues I'm having!
>
> Filip Hanik - Dev Lists wrote:
>> 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 blocking reads/writes and others, feel free to gather
>> up your thoughts in a bulleted type email instead of the essays,
>> they are a little hard to read :)
>>
>> Filip
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
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 shutdownOutput on the
underlying socket?
Regards,
Sebastiaan
P.S.: I really like Tomcat and Comet, so definately good job to you
guys! Please don't read my emails as complaints; I just want to
understand the API better and work with you guys to improve Comet by
reporting possible bugs and sharing the issues I'm having!
Filip Hanik - Dev Lists wrote:
> 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 blocking reads/writes and others, feel free to gather up your
> thoughts in a bulleted type email instead of the essays, they are a
> little hard to read :)
>
> Filip
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 blocking reads/writes and others, feel free to gather up your
thoughts in a bulleted type email instead of the essays, they are a
little hard to read :)
Filip
Sebastiaan van Erk wrote:
> 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 event (the close is done as a result of a server side
> event and not a Comet event); the other close is done deep inside of
> Tomcat. The only thing that the two have in common could be the
> request itself or the outputstream, but I don't know if Tomcat does
> any synchronization on these objects.
>
> One way to avoid this simultaneous close would seem to be this: my
> server application calls close on the OutputStream of the response, my
> client application reads the EOF (-1) and then closes the socket,
> causing an END event on the server side, in which I do any necessary
> cleanup actions.
>
> The problem is, when I try this approach, it takes my client many
> seconds (>30) to receive the EOF, instead of getting it immediately.
> That is why I was wondering what the correct way is to end a
> request/response outside of a Comet event (as a result of an
> application event). Even better would be if I could somehow trigger
> the END event on the server to finish the request and close the
> socket, so I don't have to rely on the client to play nice.
>
> BTW, I'm using the subversion version of tomcat, synched with
> subversion late yesterday evening.
>
> Regards,
> Sebastiaan
>
> Praveen Balaji wrote:
>> 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 working with events. Also, it may have a clue I'm missing.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=42198
>>
>> Also, check with the trunk to make sure you're able to reproduce your
>> defect.
>>
>> Praveen
>>
>> -----Original Message-----
>> From: Sebastiaan van Erk [mailto:sebster@sebster.com] Sent: Thursday,
>> April 26, 2007 2:07 PM
>> To: Tomcat Users List
>> Subject: how to close a comet request outside of an event?
>>
>> Hi,
>>
>> I the following Comet question; due to a server event (not a comet
>> event), I want to write some data to a client request and finish the
>> request. Currently I write the data and then call
>> OutputStream.close() on the response output stream. This seems to
>> work, except that it takes a long time before I get an END event for
>> that request. On the client this causes the EOF to the request input
>> stream to arrive very late. This is a problem, because both the
>> server and client are handling so many requests that I run out of
>> file descriptors and get the following exception (on the server):
>>
>> Apr 26, 2007 10:28:23 AM org.apache.tomcat.util.net.NioEndpoint$Acceptor
>> run
>> SEVERE: Socket accept failed
>> java.io.IOException: Too many open files
>> at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
>> at
>> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:1
>> 45)
>> at
>> org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:117
>> 7)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> Note: I'm running the client and server on the same machine, but the
>> client does not get any "Too many open files" exceptions (it does not
>> get any exceptions at all), so I'm assuming the process limit of
>> tomcat is reached, suggesting that tomcat is not closing the request
>> sockets until the END event...
>>
>> If I close the request on the client side before I get the EOF (-1) in a
>>
>> read I don't get the Too many open files problem and generally get
>> the END event immediately on the server side, but I sporadically get
>> NullPointerExceptions and AsynchronousCloseExceptions and
>> ClosedChannelExceptions on the server side in the
>> OutputStream.close() method. I figure the proper method is for the
>> client tp wait for the server to say "the request is done" (by
>> waiting for the EOF) before closing thesocket, but how do I make sure
>> it gets closed immediately on the server side if I'm not in a comet
>> event?
>>
>> Regards,
>> Sebastiaan
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: how to close a comet request outside of an event?
Posted by Sebastiaan van Erk <se...@sebster.com>.
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
event (the close is done as a result of a server side event and not a
Comet event); the other close is done deep inside of Tomcat. The only
thing that the two have in common could be the request itself or the
outputstream, but I don't know if Tomcat does any synchronization on
these objects.
One way to avoid this simultaneous close would seem to be this: my
server application calls close on the OutputStream of the response, my
client application reads the EOF (-1) and then closes the socket,
causing an END event on the server side, in which I do any necessary
cleanup actions.
The problem is, when I try this approach, it takes my client many
seconds (>30) to receive the EOF, instead of getting it immediately.
That is why I was wondering what the correct way is to end a
request/response outside of a Comet event (as a result of an application
event). Even better would be if I could somehow trigger the END event on
the server to finish the request and close the socket, so I don't have
to rely on the client to play nice.
BTW, I'm using the subversion version of tomcat, synched with subversion
late yesterday evening.
Regards,
Sebastiaan
Praveen Balaji wrote:
> 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 working with events. Also, it may have a clue I'm missing.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=42198
>
> Also, check with the trunk to make sure you're able to reproduce your
> defect.
>
> Praveen
>
> -----Original Message-----
> From: Sebastiaan van Erk [mailto:sebster@sebster.com]
> Sent: Thursday, April 26, 2007 2:07 PM
> To: Tomcat Users List
> Subject: how to close a comet request outside of an event?
>
> Hi,
>
> I the following Comet question; due to a server event (not a comet
> event), I want to write some data to a client request and finish the
> request. Currently I write the data and then call OutputStream.close()
> on the response output stream. This seems to work, except that it takes
> a long time before I get an END event for that request. On the client
> this causes the EOF to the request input stream to arrive very late.
> This is a problem, because both the server and client are handling so
> many requests that I run out of file descriptors and get the following
> exception (on the server):
>
> Apr 26, 2007 10:28:23 AM org.apache.tomcat.util.net.NioEndpoint$Acceptor
> run
> SEVERE: Socket accept failed
> java.io.IOException: Too many open files
> at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
> at
> sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:1
> 45)
> at
> org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:117
> 7)
> at java.lang.Thread.run(Thread.java:619)
>
> Note: I'm running the client and server on the same machine, but the
> client does not get any "Too many open files" exceptions (it does not
> get any exceptions at all), so I'm assuming the process limit of tomcat
> is reached, suggesting that tomcat is not closing the request sockets
> until the END event...
>
> If I close the request on the client side before I get the EOF (-1) in a
>
> read I don't get the Too many open files problem and generally get the
> END event immediately on the server side, but I sporadically get
> NullPointerExceptions and AsynchronousCloseExceptions and
> ClosedChannelExceptions on the server side in the OutputStream.close()
> method. I figure the proper method is for the client tp wait for the
> server to say "the request is done" (by waiting for the EOF) before
> closing thesocket, but how do I make sure it gets closed immediately on
> the server side if I'm not in a comet event?
>
> Regards,
> Sebastiaan
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: how to close a comet request outside of an event?
Posted by Praveen Balaji <pb...@tibco.com>.
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 working with events. Also, it may have a clue I'm missing.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42198
Also, check with the trunk to make sure you're able to reproduce your
defect.
Praveen
-----Original Message-----
From: Sebastiaan van Erk [mailto:sebster@sebster.com]
Sent: Thursday, April 26, 2007 2:07 PM
To: Tomcat Users List
Subject: how to close a comet request outside of an event?
Hi,
I the following Comet question; due to a server event (not a comet
event), I want to write some data to a client request and finish the
request. Currently I write the data and then call OutputStream.close()
on the response output stream. This seems to work, except that it takes
a long time before I get an END event for that request. On the client
this causes the EOF to the request input stream to arrive very late.
This is a problem, because both the server and client are handling so
many requests that I run out of file descriptors and get the following
exception (on the server):
Apr 26, 2007 10:28:23 AM org.apache.tomcat.util.net.NioEndpoint$Acceptor
run
SEVERE: Socket accept failed
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:1
45)
at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:117
7)
at java.lang.Thread.run(Thread.java:619)
Note: I'm running the client and server on the same machine, but the
client does not get any "Too many open files" exceptions (it does not
get any exceptions at all), so I'm assuming the process limit of tomcat
is reached, suggesting that tomcat is not closing the request sockets
until the END event...
If I close the request on the client side before I get the EOF (-1) in a
read I don't get the Too many open files problem and generally get the
END event immediately on the server side, but I sporadically get
NullPointerExceptions and AsynchronousCloseExceptions and
ClosedChannelExceptions on the server side in the OutputStream.close()
method. I figure the proper method is for the client tp wait for the
server to say "the request is done" (by waiting for the EOF) before
closing thesocket, but how do I make sure it gets closed immediately on
the server side if I'm not in a comet event?
Regards,
Sebastiaan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org