[PATCH] lingering close and event

[Jeff Trawick <tr...@gmail.com>]

has anyone played with this before?  I've seen it mentioned, and joe s
had a patch to create a linger thread for worker back in 2004

the attached patch hasn't been seriously tested (or even seriously coded)

if somebody has looked at it seriously, perhaps you can save me some time :)

Re: [PATCH] lingering close and event

[Joe Schaefer <jo...@yahoo.com>]

Yeah my patch was based on worker, not event.  Not sure
what I wrote any more, but it was likely my first crack
at thread programming, so it probably needed work.



----- Original Message ----
> From: Jeff Trawick <tr...@gmail.com>
> To: dev@httpd.apache.org
> Sent: Mon, June 13, 2011 3:09:25 PM
> Subject: Re: [PATCH] lingering close and event
> 
> On Mon, Jun 13, 2011 at 2:56 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> > Hi  Jeff,
> >
> > On Tuesday 26 April 2011, Jeff Trawick wrote:
> >>  has anyone played with this before?  I've seen it mentioned, and
> >> joe  s had a patch to create a linger thread for worker back in
> >>  2004
> >>
> >> the attached patch hasn't been seriously tested (or  even seriously
> >> coded)
> >>
> >> if somebody has looked  at it seriously, perhaps you can save me
> >> some time  :)
> >
> > I have looked at limiting the maximum connections per-process  for
> > event (see STATUS) and think that would be easier to implement if  the
> > lingering close would be done by the listener thread. Two  questions:
> >
> > Did you have a chance to work on this further? If  yes, can you post
> > the latest version?
> 
> not yet; would love  to
> 
> but even better would be to have someone else take it up  :)
> 
> >
> > Is your patch based on the work by joe s? I mean if I  commit something
> > based on your patch, should I mention him in the  credit, too?
> 
> not based on his work
> 
> I saw Joe S's patch when  looking for prior conversations on the topic;
> ISTR that it has a totally  different implementation predating event
> and its particular connection  state????
> 

Re: [PATCH] lingering close and event

[Stefan Fritsch <sf...@sfritsch.de>]

On Monday 13 June 2011, Jeff Trawick wrote:
> > I have looked at limiting the maximum connections per-process for
> > event (see STATUS) and think that would be easier to implement if
> > the lingering close would be done by the listener thread. Two
> > questions:
> > 
> > Did you have a chance to work on this further? If yes, can you
> > post the latest version?
> 
> not yet; would love to

NP

> but even better would be to have someone else take it up :)

I hope I will have some time in the next 1-2 weeks.

Re: [PATCH] lingering close and event

[Jeff Trawick <tr...@gmail.com>]

On Mon, Jun 13, 2011 at 2:56 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> Hi Jeff,
>
> On Tuesday 26 April 2011, Jeff Trawick wrote:
>> has anyone played with this before?  I've seen it mentioned, and
>> joe s had a patch to create a linger thread for worker back in
>> 2004
>>
>> the attached patch hasn't been seriously tested (or even seriously
>> coded)
>>
>> if somebody has looked at it seriously, perhaps you can save me
>> some time :)
>
> I have looked at limiting the maximum connections per-process for
> event (see STATUS) and think that would be easier to implement if the
> lingering close would be done by the listener thread. Two questions:
>
> Did you have a chance to work on this further? If yes, can you post
> the latest version?

not yet; would love to

but even better would be to have someone else take it up :)

>
> Is your patch based on the work by joe s? I mean if I commit something
> based on your patch, should I mention him in the credit, too?

not based on his work

I saw Joe S's patch when looking for prior conversations on the topic;
ISTR that it has a totally different implementation predating event
and its particular connection state????

Re: [PATCH] lingering close and event

[Stefan Fritsch <sf...@sfritsch.de>]

Hi Jeff,

On Tuesday 26 April 2011, Jeff Trawick wrote:
> has anyone played with this before?  I've seen it mentioned, and
> joe s had a patch to create a linger thread for worker back in
> 2004
> 
> the attached patch hasn't been seriously tested (or even seriously
> coded)
> 
> if somebody has looked at it seriously, perhaps you can save me
> some time :)

I have looked at limiting the maximum connections per-process for 
event (see STATUS) and think that would be easier to implement if the 
lingering close would be done by the listener thread. Two questions:

Did you have a chance to work on this further? If yes, can you post 
the latest version?

Is your patch based on the work by joe s? I mean if I commit something 
based on your patch, should I mention him in the credit, too?

Cheers,
Stefan

Re: [PATCH] lingering close and event

[Greg Ames <am...@gmail.com>]

hey I like the concept a lot!  a quick peek at
http://apache.org/server-status shows 15 Cs for threads tied up in lingering
close, something like 50 Keepalive threads, and only 13 threads actually
reading or writing.

On Mon, Apr 25, 2011 at 8:53 PM, Jeff Trawick <tr...@gmail.com> wrote:

> has anyone played with this before?  I've seen it mentioned, and joe s
> had a patch to create a linger thread for worker back in 2004
>
> +            apr_thread_mutex_lock(timeout_mutex);
+            APR_RING_INSERT_TAIL(&recv_fin_timeout_head, cs,
conn_state_t, timeout_list);
+            apr_thread_mutex_unlock(timeout_mutex);

I see where the cs is removed from the ring for the timeout flow.  but what
about for the normal non-timeout flow?

     rv = apr_pollset_create(&event_pollset,
-                            threads_per_child,
+                            threads_per_child, /* XXX don't we need
more, to handle
+                                                * connections in K-A
or lingering
+                                                * close?
+                                                */

IIRC the second arg to apr_pollset_create determines the size of the revents
array used to report ready file descriptors.  If there are ever more ready
fds than slots in the array, it's no big deal.  They get reported as ready
on the next apr_pollset_poll call.  So using threads_per_child is just
picking a number out of the air which happens to go up automatically as the
worker process is configured for higher workloads.

Greg