Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <D047B57B-A204-42F1-8B19-006CBC76F57D@jaguNET.com>
References: <4592036.VMXMpTd4BY@k> <6BC2F18F-D161-4580-B92E-7B083D95F3F4@sharp.fm>
 <alpine.DEB.2.11.1609181049040.2382@manul.sfritsch.de> <CAFedD43i6m65mM9hX5xOPoio3z7CDEaOfAYD8dOM69rqcnLfHw@mail.gmail.com>
 <D9A02BB6-883A-4161-AD91-9C1349811380@sharp.fm> <D047B57B-A204-42F1-8B19-006CBC76F57D@jaguNET.com>
From: Luca Toscano <toscano.luca@gmail.com>
Date: Wed, 18 Jan 2017 14:25:46 +0100
Message-ID: <CAFedD43pMmrCe4dqi89R4k7bqdT=m4OGSfifQ72nHHs_LJg21Q@mail.gmail.com>
Subject: Re: Async write completion broken in trunk?
To: Apache HTTP Server Development List <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a11452e4cc5aca005465e5acc
archived-at: Wed, 18 Jan 2017 13:25:58 -0000

--001a11452e4cc5aca005465e5acc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-01-18 14:00 GMT+01:00 Jim Jagielski <jim@jagunet.com>:

>
> > On Jan 18, 2017, at 7:50 AM, Graham Leggett <minfrin@sharp.fm> wrote:
> >
> > On 17 Jan 2017, at 7:40 PM, Luca Toscano <toscano.luca@gmail.com> wrote=
:
> >
> >> Since this email thread seems important, is there any update from
> anybody working on it? It would be great to open a bugzilla task otherwis=
e,
> to track everything and make sure that we don't forget about it :)
> >
> > I looked at this a while back - I found that pipelining support is
> causing the blocking.
> >
> > When we=E2=80=99re handling pipelined requests and we reach a limit, we=
 block.
> What we should be doing instead is looping round back to WRITE_COMPLETION=
,
> waiting for permission to write again. This should be reasonably
> straightforward to fix, but my financial year end is the end of this mont=
h
> so can=E2=80=99t look at this till February.
> >
> > I suspect pipelining support has been suppressed in v2.4.x event MPM,
> and was at some point =E2=80=9Cfixed=E2=80=9D on trunk, bringing this pro=
blem back.
> >
>
> Somewhat on-topic but also off-topic as well, but it does seem
> that event on trunk is getting much more fragile instead of more
> stable. It seems to be picking up some kruft which is making
> event on trunk a *worse* option than what's in 2.4, despite a deeper
> async alignment.
>
>
My 2c view on this is that mpm-event has been getting better during the
last months, but the nature of the changes, together with the fact that we
have not developed a good way to test regressions, causes long running
debugging tasks. In the case of the wake-ups, we are basically testing a
new big feature thanks to live traffic from Stefan Priebe (thanks again for
the help btw!), meanwhile it would be really great to have some sort of
test to fake traffic and spot problems (that would absolutely not
substitute the invaluable user feedback of course).

Luca

--001a11452e4cc5aca005465e5acc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-01-18 14:00 GMT+01:00 Jim Jagielski <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jim@jagunet.com" target=3D"_blank">jim@jagunet.com</a>&gt;</span=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span><br>
&gt; On Jan 18, 2017, at 7:50 AM, Graham Leggett &lt;<a href=3D"mailto:minf=
rin@sharp.fm" target=3D"_blank">minfrin@sharp.fm</a>&gt; wrote:<br>
&gt;<br>
&gt; On 17 Jan 2017, at 7:40 PM, Luca Toscano &lt;<a href=3D"mailto:toscano=
.luca@gmail.com" target=3D"_blank">toscano.luca@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>
&gt;&gt; Since this email thread seems important, is there any update from =
anybody working on it? It would be great to open a bugzilla task otherwise,=
 to track everything and make sure that we don&#39;t forget about it :)<br>
&gt;<br>
&gt; I looked at this a while back - I found that pipelining support is cau=
sing the blocking.<br>
&gt;<br>
&gt; When we=E2=80=99re handling pipelined requests and we reach a limit, w=
e block. What we should be doing instead is looping round back to WRITE_COM=
PLETION, waiting for permission to write again. This should be reasonably s=
traightforward to fix, but my financial year end is the end of this month s=
o can=E2=80=99t look at this till February.<br>
&gt;<br>
&gt; I suspect pipelining support has been suppressed in v2.4.x event MPM, =
and was at some point =E2=80=9Cfixed=E2=80=9D on trunk, bringing this probl=
em back.<br>
&gt;<br>
<br>
</span>Somewhat on-topic but also off-topic as well, but it does seem<br>
that event on trunk is getting much more fragile instead of more<br>
stable. It seems to be picking up some kruft which is making<br>
event on trunk a *worse* option than what&#39;s in 2.4, despite a deeper<br=
>
async alignment.<br>
<br>
</blockquote></div><br></div><div class=3D"gmail_extra">My 2c view on this =
is that mpm-event has been getting better during the last months, but the n=
ature of the changes, together with the fact that we have not developed a g=
ood way to test regressions, causes long running debugging tasks. In the ca=
se of the wake-ups, we are basically testing a new big feature thanks to li=
ve traffic from Stefan Priebe (thanks again for the help btw!), meanwhile i=
t would be really great to have some sort of test to fake traffic and spot =
problems (that would absolutely not substitute the invaluable user feedback=
 of course).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">Luca=C2=A0</div><div class=3D"gmail_extra"><br></div></div>

--001a11452e4cc5aca005465e5acc--