Home > Archive > PERL POE > May 2007 > POE::Component::Server::HTTP, Keep alive, and leaking sockets
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
POE::Component::Server::HTTP, Keep alive, and leaking sockets
|
|
| Eric Busto 2007-03-21, 7:17 pm |
| From what I have gathered, for a web server to be HTTP 1.1 compliant, it
must support keep alive, and keep alive is enabled by default.
When using POE::Component::Server::HTTP in its simple case, as in the
cookbook entry
http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
the connections open even after the event for the URL request has been
handled causes file descriptors to "leak" as the socket will not get
closed.
I can force the connection to get closed after the ContentHandler
triggers by having a PreHandler like so:
POE::Component::Server::HTTP->new (
Port => 80,
PreHandler => {
'/' => sub { $_[0]->header(Connection =>
'close') }
},
ContentHandler => {
'/' => \&web_status,
}
}
My question is, is this the "right" thing to do? Is there a more
elegant method, or am I missing something that should be obvious? If
I'm not missing anything, should this be added to the cookbook page for
a basic web server with PoCo::Server::HTTP?
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
| |
| Mathieu Longtin 2007-03-21, 7:17 pm |
| My memory is fuzzy, but I think if you close the browser, especially if it's
local, the sockets closes. I remember IE keeping the connections alive for a
while.
On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> From what I have gathered, for a web server to be HTTP 1.1 compliant, it
> must support keep alive, and keep alive is enabled by default.
>
> When using POE::Component::Server::HTTP in its simple case, as in the
> cookbook entry
> http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
> the connections open even after the event for the URL request has been
> handled causes file descriptors to "leak" as the socket will not get
> closed.
>
> I can force the connection to get closed after the ContentHandler
> triggers by having a PreHandler like so:
> POE::Component::Server::HTTP->new (
> Port => 80,
> PreHandler => {
> '/' => sub { $_[0]->header(Connection =>
> 'close') }
> },
> ContentHandler => {
> '/' => \&web_status,
> }
> }
>
> My question is, is this the "right" thing to do? Is there a more
> elegant method, or am I missing something that should be obvious? If
> I'm not missing anything, should this be added to the cookbook page for
> a basic web server with PoCo::Server::HTTP?
>
>
>
>
>
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information. Any unauthorized review, use, disclosure or
> distribution
> is prohibited. If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
>
> -----------------------------------------------------------------------------------
>
--
Mathieu Longtin
| |
| Eric Busto 2007-03-21, 7:17 pm |
| Firefox seems to keep them alive as well. Unfortunately, since the app
I am writing uses a meta refresh every few seconds to have the browser
reload it, a browser left up overnight will easily cause the app to run
out of file descriptors.
-----Original Message-----
From: mathieu.longtin@gmail.com
[mailto:mathieu.longtin@gmail.com] On Behalf Of Mathieu Longtin
Sent: Wednesday, March 21, 2007 12:27 PM
To: Eric Busto
Cc: poe@perl.org
Subject: Re: POE::Component::Server::HTTP, Keep alive, and
leaking sockets
My memory is fuzzy, but I think if you close the browser,
especially if it's local, the sockets closes. I remember IE keeping the
connections alive for a while.
On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
From what I have gathered, for a web server to be HTTP
1.1 compliant, it
must support keep alive, and keep alive is enabled by
default.
When using POE::Component::Server::HTTP in its simple
case, as in the
cookbook entry
http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
the connections open even after the event for the URL
request has been
handled causes file descriptors to "leak" as the socket
will not get
closed.
I can force the connection to get closed after the
ContentHandler
triggers by having a PreHandler like so:
POE::Component::Server::HTTP->new (
Port => 80,
PreHandler => {
'/' => sub {
$_[0]->header(Connection =>
'close') }
},
ContentHandler => {
'/' => \&web_status,
}
}
My question is, is this the "right" thing to do? Is
there a more
elegant method, or am I missing something that should be
obvious? If
I'm not missing anything, should this be added to the
cookbook page for
a basic web server with PoCo::Server::HTTP?
------------------------------------------------------------------------
-----------
This email message is for the sole use of the intended
recipient(s) and may contain
confidential information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not the intended recipient,
please contact the sender by
reply email and destroy all copies of the original
message.
------------------------------------------------------------------------
-----------
--
Mathieu Longtin
| |
| Matt Sickler 2007-03-21, 7:17 pm |
| A better fix would be a patch to the source that fixes the leak
On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> Firefox seems to keep them alive as well. Unfortunately, since the app
> I am writing uses a meta refresh every few seconds to have the browser
> reload it, a browser left up overnight will easily cause the app to run
> out of file descriptors.
>
> -----Original Message-----
> From: mathieu.longtin@gmail.com
> [mailto:mathieu.longtin@gmail.com] On Behalf Of Mathieu Longtin
> Sent: Wednesday, March 21, 2007 12:27 PM
> To: Eric Busto
> Cc: poe@perl.org
> Subject: Re: POE::Component::Server::HTTP, Keep alive, and
> leaking sockets
>
>
> My memory is fuzzy, but I think if you close the browser,
> especially if it's local, the sockets closes. I remember IE keeping the
> connections alive for a while.
>
>
> On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> From what I have gathered, for a web server to be HTTP
> 1.1 compliant, it
> must support keep alive, and keep alive is enabled by
> default.
>
> When using POE::Component::Server::HTTP in its simple
> case, as in the
> cookbook entry
>
> http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
> the connections open even after the event for the URL
> request has been
> handled causes file descriptors to "leak" as the socket
> will not get
> closed.
>
> I can force the connection to get closed after the
> ContentHandler
> triggers by having a PreHandler like so:
> POE::Component::Server::HTTP->new (
> Port => 80,
> PreHandler => {
> '/' => sub {
> $_[0]->header(Connection =>
> 'close') }
> },
> ContentHandler => {
> '/' => \&web_status,
> }
> }
>
> My question is, is this the "right" thing to do? Is
> there a more
> elegant method, or am I missing something that should be
> obvious? If
> I'm not missing anything, should this be added to the
> cookbook page for
> a basic web server with PoCo::Server::HTTP?
>
>
>
>
>
>
> ------------------------------------------------------------------------
> -----------
> This email message is for the sole use of the intended
> recipient(s) and may contain
> confidential information. Any unauthorized review, use,
> disclosure or distribution
> is prohibited. If you are not the intended recipient,
> please contact the sender by
> reply email and destroy all copies of the original
> message.
>
> ------------------------------------------------------------------------
> -----------
>
>
>
>
>
> --
> Mathieu Longtin
>
>
| |
| Eric Busto 2007-03-21, 7:17 pm |
| In this situation, it isn't entirely clear what layer should take
responsibility for closing sockets when they are no longer needed.
PoCo::Server::HTTP doesn't necessarily know if the browser is going to
make another request over the same socket. By default, in accordance
with HTTP 1.1 (I believe), the socket is just left open.
The application that is using PoCo::Server::HTTP may or may not know.
It would be simpler if there was a way to tell PoCo::HTTP::Server to
just do one request per socket. I had to dig into the code to find out
the solution I'm using with the PreHandler. Requiring a programmer who
is considering using POE to dig in may slow down adoption a bit. :-)
-----Original Message-----
From: Matt Sickler [mailto:crazyfordynamite@gmail.com]=20
Sent: Wednesday, March 21, 2007 12:56 PM
To: Eric Busto
Cc: Mathieu Longtin; poe@perl.org
Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
sockets
A better fix would be a patch to the source that fixes the leak
On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> Firefox seems to keep them alive as well. Unfortunately, since the
app
> I am writing uses a meta refresh every few seconds to have the browser
> reload it, a browser left up overnight will easily cause the app to
run
> out of file descriptors.
>
> -----Original Message-----
> From: mathieu.longtin@gmail.com
> [mailto:mathieu.longtin@gmail.com] On Behalf Of Mathieu Longtin
> Sent: Wednesday, March 21, 2007 12:27 PM
> To: Eric Busto
> Cc: poe@perl.org
> Subject: Re: POE::Component::Server::HTTP, Keep alive, and
> leaking sockets
>
>
> My memory is fuzzy, but I think if you close the browser,
> especially if it's local, the sockets closes. I remember IE keeping
the
> connections alive for a while.
>
>
> On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> From what I have gathered, for a web server to be HTTP
> 1.1 compliant, it
> must support keep alive, and keep alive is enabled by
> default.
>
> When using POE::Component::Server::HTTP in its simple
> case, as in the
> cookbook entry
>
> http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
> the connections open even after the event for the URL
> request has been
> handled causes file descriptors to "leak" as the socket
> will not get
> closed.
>
> I can force the connection to get closed after the
> ContentHandler
> triggers by having a PreHandler like so:
> POE::Component::Server::HTTP->new (
> Port =3D> 80,
> PreHandler =3D> {
> '/' =3D> sub {
> $_[0]->header(Connection =3D>
> 'close') }
> },
> ContentHandler =3D> {
> '/' =3D> \&web_status,
> }
> }
>
> My question is, is this the "right" thing to do? Is
> there a more
> elegant method, or am I missing something that should
be
> obvious? If
> I'm not missing anything, should this be added to the
> cookbook page for
> a basic web server with PoCo::Server::HTTP?
>
>
>
>
>
>
>
------------------------------------------------------------------------
> -----------
> This email message is for the sole use of the intended
> recipient(s) and may contain
> confidential information. Any unauthorized review,
use,
> disclosure or distribution
> is prohibited. If you are not the intended recipient,
> please contact the sender by
> reply email and destroy all copies of the original
> message.
>
>
------------------------------------------------------------------------
> -----------
>
>
>
>
>
> --
> Mathieu Longtin
>
>
| |
| Andy Grundman 2007-03-21, 7:17 pm |
|
On Mar 21, 2007, at 1:00 PM, Eric Busto wrote:
> In this situation, it isn't entirely clear what layer should take
> responsibility for closing sockets when they are no longer needed.
>
> PoCo::Server::HTTP doesn't necessarily know if the browser is going to
> make another request over the same socket. By default, in accordance
> with HTTP 1.1 (I believe), the socket is just left open.
The socket should be closed by the server after a certain timeout
period, for example apache uses 15 seconds as the default time out
for keep-alive connections (KeepAliveTimeout).
| |
| Eric Busto 2007-03-21, 7:17 pm |
| Cool, sounds simple.
How do you do that when using PoCo::Server::HTTP? Closing a response is
mentioned in the context of streaming on the perldoc page.
Since most people use the cookbook, I imagine, when they first start
writing POE based programs, should how to close the connection when
finished be added?
-----Original Message-----
From: Andy Grundman [mailto:andy@hybridized.org]=20
Sent: Wednesday, March 21, 2007 1:08 PM
To: poe@perl.org
Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
sockets
On Mar 21, 2007, at 1:00 PM, Eric Busto wrote:
> In this situation, it isn't entirely clear what layer should take
> responsibility for closing sockets when they are no longer needed.
>
> PoCo::Server::HTTP doesn't necessarily know if the browser is going to
> make another request over the same socket. By default, in accordance
> with HTTP 1.1 (I believe), the socket is just left open.
The socket should be closed by the server after a certain timeout =20
period, for example apache uses 15 seconds as the default time out =20
for keep-alive connections (KeepAliveTimeout).
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information. Any unauthorized review, use, disclosure or di=
stribution
is prohibited. If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------
| |
| Andy Grundman 2007-03-21, 7:17 pm |
|
On Mar 21, 2007, at 1:12 PM, Eric Busto wrote:
> Cool, sounds simple.
>
> How do you do that when using PoCo::Server::HTTP? Closing a
> response is
> mentioned in the context of streaming on the perldoc page.
>
> Since most people use the cookbook, I imagine, when they first start
> writing POE based programs, should how to close the connection when
> finished be added?
I haven't use Server::HTTP myself, but this sort of thing should
probably be handled automatically by Server::HTTP. You really
shouldn't have to think about it when writing your own server.
| |
| Eric Busto 2007-03-21, 7:17 pm |
| Right, which was more or less my point. :)
Currently, however, you -do- have to think about it. I'm not suggesting
the behavior of PoCo::HTTP::Server be changed to have keep alive
disabled by default, but with the way things are now, a long running
application that uses PoCo::HTTP::Server and receives actual HTTP
requests will leak sockets, if the code is taken straight from the
cookbook example.
-----Original Message-----
From: Andy Grundman [mailto:andy@hybridized.org]=20
Sent: Wednesday, March 21, 2007 1:29 PM
To: poe@perl.org
Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
sockets
On Mar 21, 2007, at 1:12 PM, Eric Busto wrote:
> Cool, sounds simple.
>
> How do you do that when using PoCo::Server::HTTP? Closing a =20
> response is
> mentioned in the context of streaming on the perldoc page.
>
> Since most people use the cookbook, I imagine, when they first start
> writing POE based programs, should how to close the connection when
> finished be added?
I haven't use Server::HTTP myself, but this sort of thing should =20
probably be handled automatically by Server::HTTP. You really =20
shouldn't have to think about it when writing your own server.
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information. Any unauthorized review, use, disclosure or di=
stribution
is prohibited. If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------
| |
| Nicholas Perez 2007-03-21, 7:17 pm |
| Well, if apache does a timeout thingy, you can do it in
PoCo::Server::HTTP with a simple alarm.
Looking at the source, the connections are tracked, so all you need to
do is set an alarm to kill the connection if there isn't any activity
after a certain amount of time and track activity within input().
Obviously this requires changes to source and a patch sent upstream.
CPANIDs of maintainers: ABERGMAN, RCLAMP
HTH
On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
> Right, which was more or less my point. :)
>
> Currently, however, you -do- have to think about it. I'm not suggesting
> the behavior of PoCo::HTTP::Server be changed to have keep alive
> disabled by default, but with the way things are now, a long running
> application that uses PoCo::HTTP::Server and receives actual HTTP
> requests will leak sockets, if the code is taken straight from the
> cookbook example.
>
>
> -----Original Message-----
> From: Andy Grundman [mailto:andy@hybridized.org]
> Sent: Wednesday, March 21, 2007 1:29 PM
> To: poe@perl.org
> Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
> sockets
>
>
>
> On Mar 21, 2007, at 1:12 PM, Eric Busto wrote:
>
>
> I haven't use Server::HTTP myself, but this sort of thing should
> probably be handled automatically by Server::HTTP. You really
> shouldn't have to think about it when writing your own server.
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
>
| |
| Rocco Caputo 2007-03-24, 4:21 am |
| Something doesn't add up. Maybe I'm missing a pertinent fact.
On one hand, if sockets are being kept alive between requests, why is
Firefox opening a new socket for each request?
On the other hand, if Firefox is opening a new socket for each
request, why isn't it closing the old ones?
Why isn't Firefox also running out of file descriptors, if it's
opening new sockets without closing old ones?
--
Rocco Caputo - rcaputo@pobox.com
On Mar 21, 2007, at 15:50, Eric Busto wrote:
> Firefox seems to keep them alive as well. Unfortunately, since the
> app
> I am writing uses a meta refresh every few seconds to have the browser
> reload it, a browser left up overnight will easily cause the app to
> run
> out of file descriptors.
>
> -----Original Message-----
> From: mathieu.longtin@gmail.com
> [mailto:mathieu.longtin@gmail.com] On Behalf Of Mathieu Longtin
> Sent: Wednesday, March 21, 2007 12:27 PM
> To: Eric Busto
> Cc: poe@perl.org
> Subject: Re: POE::Component::Server::HTTP, Keep alive, and
> leaking sockets
>
>
> My memory is fuzzy, but I think if you close the browser,
> especially if it's local, the sockets closes. I remember IE keeping
> the
> connections alive for a while.
>
>
> On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> From what I have gathered, for a web server to be HTTP
> 1.1 compliant, it
> must support keep alive, and keep alive is enabled by
> default.
>
> When using POE::Component::Server::HTTP in its simple
> case, as in the
> cookbook entry
>
> http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
> the connections open even after the event for the URL
> request has been
> handled causes file descriptors to "leak" as the socket
> will not get
> closed.
>
> I can force the connection to get closed after the
> ContentHandler
> triggers by having a PreHandler like so:
> POE::Component::Server::HTTP->new (
> Port => 80,
> PreHandler => {
> '/' => sub {
> $_[0]->header(Connection =>
> 'close') }
> },
> ContentHandler => {
> '/' => \&web_status,
> }
> }
>
> My question is, is this the "right" thing to do? Is
> there a more
> elegant method, or am I missing something that should be
> obvious? If
> I'm not missing anything, should this be added to the
> cookbook page for
> a basic web server with PoCo::Server::HTTP?
| |
| David Davis 2007-03-24, 4:21 am |
| I used 'sudo ngrep port 32080' and watched ls /proc/<pid>/fd/ while I hit
the http server.
I noticed that the responses were HTTP/1.0 but I didn't see a connection:
close header.
So, I set $response->protocol( "HTTP/1.1" ); in the cookbook example, and
the sockets didn't leak!
I think we have a few options
1) The server should assume connection: close if the protocol is < 1.1 and
no keepalive is being used.
2) The PoCo could set HTTP/1.1 in the response by default.
3) both.
I haven't dug any deeper yet, but it's a good start.
Comments?
David
On 3/23/07, Rocco Caputo <rcaputo@pobox.com> wrote:
>
> Something doesn't add up. Maybe I'm missing a pertinent fact.
>
> On one hand, if sockets are being kept alive between requests, why is
> Firefox opening a new socket for each request?
>
> On the other hand, if Firefox is opening a new socket for each
> request, why isn't it closing the old ones?
>
> Why isn't Firefox also running out of file descriptors, if it's
> opening new sockets without closing old ones?
>
> --
> Rocco Caputo - rcaputo@pobox.com
>
>
> On Mar 21, 2007, at 15:50, Eric Busto wrote:
>
>
| |
| Maciej Pijanka 2007-03-27, 4:34 am |
| On 24/03/07, David Davis <david.davis@gmail.com> wrote:
> I used 'sudo ngrep port 32080' and watched ls /proc/<pid>/fd/ while I hit
> the http server.
> I noticed that the responses were HTTP/1.0 but I didn't see a connection:
> close header.
> So, I set $response->protocol( "HTTP/1.1" ); in the cookbook example, and
> the sockets didn't leak!
> I think we have a few options
> 1) The server should assume connection: close if the protocol is < 1.1 and
> no keepalive is being used.
> 2) The PoCo could set HTTP/1.1 in the response by default.
> 3) both.
>
> I haven't dug any deeper yet, but it's a good start.
yesterday i had similar problem, ie app was running out of sockets
(because PoCo server never closed them (or at least not soon after)).
My solution was PostHandler enforcing Connection => 'Close',
It even keeps them opened when calling aplication closes their socket and exits.
I think when error handler in PoCo::Server::HTTP catches read/write
error should mark that socket will be closed even if conection
keepalive is in effect, because read/write error mean peer
disconnected (and looks like thats mine case)
test app in attachment.
--
Maciej Pijanka, PLD-Linux Developer (lazy one)
Registerd Linux user #133161 (as lazy as hell)
A train station is where a train stops. A bus station is where a bus
stops. On my desk I have a workstation...
| |
| Eric Busto 2007-03-27, 7:25 pm |
| Sorry, I should have provided a test case. Busy and all that.
Using Maciej's test case, I'm able to reproduce the problem I was having
(just be sure to comment out the header('Connection' =3D> 'Close') lines)=
..
You can watch the number of sockets with lsof -p process_id | grep IPv4
| wc -l.
-----Original Message-----
From: Maciej Pijanka [mailto:maciej.pijanka@gmail.com]=20
Sent: Tuesday, March 27, 2007 1:51 AM
To: POE List
Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
sockets
On 24/03/07, David Davis <david.davis@gmail.com> wrote:
> I used 'sudo ngrep port 32080' and watched ls /proc/<pid>/fd/ while I
hit
> the http server.
> I noticed that the responses were HTTP/1.0 but I didn't see a
connection:
> close header.
> So, I set $response->protocol( "HTTP/1.1" ); in the cookbook example,
and
> the sockets didn't leak!
> I think we have a few options
> 1) The server should assume connection: close if the protocol is < 1.1
and
> no keepalive is being used.
> 2) The PoCo could set HTTP/1.1 in the response by default.
> 3) both.
>
> I haven't dug any deeper yet, but it's a good start.
yesterday i had similar problem, ie app was running out of sockets
(because PoCo server never closed them (or at least not soon after)).
My solution was PostHandler enforcing Connection =3D> 'Close',
It even keeps them opened when calling aplication closes their socket
and exits.
I think when error handler in PoCo::Server::HTTP catches read/write
error should mark that socket will be closed even if conection
keepalive is in effect, because read/write error mean peer
disconnected (and looks like thats mine case)
test app in attachment.
--=20
Maciej Pijanka, PLD-Linux Developer (lazy one)
Registerd Linux user #133161 (as lazy as hell)
A train station is where a train stops. A bus station is where a bus
stops. On my desk I have a workstation...
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information. Any unauthorized review, use, disclosure or di=
stribution
is prohibited. If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------
| |
| Eric Busto 2007-03-27, 7:25 pm |
| The sockets aren't completely open, they are in the CLOSE_WAIT state, so
Firefox may have closed the socket on the remote side (and sent a FIN),
but the local application has yet to close the socket.
-----Original Message-----
From: Rocco Caputo [mailto:rcaputo@pobox.com]=20
Sent: Friday, March 23, 2007 9:26 PM
To: POE List
Subject: Re: POE::Component::Server::HTTP, Keep alive, and leaking
sockets
Something doesn't add up. Maybe I'm missing a pertinent fact.
On one hand, if sockets are being kept alive between requests, why is =20
Firefox opening a new socket for each request?
On the other hand, if Firefox is opening a new socket for each =20
request, why isn't it closing the old ones?
Why isn't Firefox also running out of file descriptors, if it's =20
opening new sockets without closing old ones?
--=20
Rocco Caputo - rcaputo@pobox.com
On Mar 21, 2007, at 15:50, Eric Busto wrote:
> Firefox seems to keep them alive as well. Unfortunately, since the =20
> app
> I am writing uses a meta refresh every few seconds to have the browser
> reload it, a browser left up overnight will easily cause the app to =20
> run
> out of file descriptors.
>
> -----Original Message-----
> From: mathieu.longtin@gmail.com
> [mailto:mathieu.longtin@gmail.com] On Behalf Of Mathieu Longtin
> Sent: Wednesday, March 21, 2007 12:27 PM
> To: Eric Busto
> Cc: poe@perl.org
> Subject: Re: POE::Component::Server::HTTP, Keep alive, and
> leaking sockets
> =09
> =09
> My memory is fuzzy, but I think if you close the browser,
> especially if it's local, the sockets closes. I remember IE keeping =20
> the
> connections alive for a while.
> =09
> =09
> On 3/21/07, Eric Busto <EBusto@nvidia.com> wrote:
>
> From what I have gathered, for a web server to be HTTP
> 1.1 compliant, it
> must support keep alive, and keep alive is enabled by
> default.
> =09
> When using POE::Component::Server::HTTP in its simple
> case, as in the
> cookbook entry
> =09
> http://poe.perl.org/?POE_Cookbook/W...ith_Components, keeping
> the connections open even after the event for the URL
> request has been
> handled causes file descriptors to "leak" as the socket
> will not get
> closed.
> =09
> I can force the connection to get closed after the
> ContentHandler
> triggers by having a PreHandler like so:
> POE::Component::Server::HTTP->new (
> Port =3D> 80,
> PreHandler =3D> {
> '/' =3D> sub {
> $_[0]->header(Connection =3D>
> 'close') }
> },
> ContentHandler =3D> {
> '/' =3D> \&web_status,
> }
> }
> =09
> My question is, is this the "right" thing to do? Is
> there a more
> elegant method, or am I missing something that should be
> obvious? If
> I'm not missing anything, should this be added to the
> cookbook page for
> a basic web server with PoCo::Server::HTTP?
-------------------------------------------------------------------------=
----------
This email message is for the sole use of the intended recipient(s) and m=
ay contain
confidential information. Any unauthorized review, use, disclosure or di=
stribution
is prohibited. If you are not the intended recipient, please contact the=
=20sender by
reply email and destroy all copies of the original message.
-------------------------------------------------------------------------=
----------
| |
|
|
|
|
|
|
|
|
|
|
|