On 1/29/24 12:25 PM, Yann Ylavic wrote:
That's where we are, I think, if this first/light patch eventually
helps significantly with the "local" graceful-stop which you care
about still, it's possibly worth it since it requires no opt-in (but
needs testing..), but going further looks
On Mon, Jan 29, 2024 at 4:59 PM Sherrard Burton wrote:
>
> On 1/29/24 10:17 AM, Yann Ylavic wrote:
> > On Mon, Jan 29, 2024 at 3:06 PM Eric Covener wrote:
> >
> > The patch helps in this case because we no longer close the listening
> > sockets unconditionally, I mean without first checking if
On 1/29/24 10:17 AM, Yann Ylavic wrote:
On Mon, Jan 29, 2024 at 3:06 PM Eric Covener wrote:
The patch helps in this case because we no longer close the listening
sockets unconditionally, I mean without first checking if there are
new connections in the backlog. So I thought the option was
On 1/29/24 9:05 AM, Eric Covener wrote:
Maybe I wasn't clear enough but this patch makes sense only if there
is something in place that prevents new connections from arriving at
the stopping httpd children processes (like a frontend/load-balancer
or a tcp/bpf filter), otherwise they may never
On 1/29/24 8:59 AM, Yann Ylavic wrote:
Maybe I wasn't clear enough but this patch makes sense only if there
is something in place that prevents new connections from arriving at
the stopping httpd children processes (like a frontend/load-balancer
or a tcp/bpf filter), otherwise they may never
On Mon, Jan 29, 2024 at 4:21 PM Eric Covener wrote:
>
> > > It seems to me If there is no such LB/VIP that stops new connections
> > > from landing on this server, the new option should be avoided.
> >
> > Correct.
> >
> > > But if there is such a LB/VIP, the option is not really needed. Is it
> > It seems to me If there is no such LB/VIP that stops new connections
> > from landing on this server, the new option should be avoided.
>
> Correct.
>
> > But if there is such a LB/VIP, the option is not really needed. Is it fair?
>
> The patch helps in this case because we no longer close
On Mon, Jan 29, 2024 at 3:06 PM Eric Covener wrote:
>
> > Maybe I wasn't clear enough but this patch makes sense only if there
> > is something in place that prevents new connections from arriving at
> > the stopping httpd children processes (like a frontend/load-balancer
> > or a tcp/bpf
> Maybe I wasn't clear enough but this patch makes sense only if there
> is something in place that prevents new connections from arriving at
> the stopping httpd children processes (like a frontend/load-balancer
> or a tcp/bpf filter), otherwise they may never really stop which does
> not help
On Mon, Jan 29, 2024 at 2:23 PM Yann Ylavic wrote:
>
> On Sun, Jan 28, 2024 at 5:26 AM Sherrard Burton wrote:
> >
> > On 1/27/24 09:46 PM, Eric Covener wrote:
> > >
> > > Both worker and event MPMs have a dedicated listener thread per child
> > > process, so it will close those copies of the
On Sun, Jan 28, 2024 at 5:26 AM Sherrard Burton wrote:
>
> On 1/27/24 09:46 PM, Eric Covener wrote:
> >
> > Both worker and event MPMs have a dedicated listener thread per child
> > process, so it will close those copies of the listening sockets much
> > more quickly.
>
> so that i am clear, are
11 matches
Mail list logo
