Re: svn commit: r1774544 - /httpd/httpd/branches/2.4.x/STATUS
On Fri, Dec 16, 2016 at 1:10 AM, wrote: > Author: ylavic > Date: Fri Dec 16 00:10:40 2016 > New Revision: 1774544 > > URL: http://svn.apache.org/viewvc?rev=1774544&view=rev > Log: > Propose. > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1774544&r1=1774543&r2=1774544&view=diff > == > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Fri Dec 16 00:10:40 2016 > @@ -142,6 +142,12 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > ylavic: reverted, see discussion on dev@ and r1774538 if you still > think a backport is necessary. > > + *) event: close a race condition where we might re-enable listeners while > they > + are already or about to be closed. > + trunk patch: http://svn.apache.org/r1774541 > + 2.4.x patch: trunk works > + +1: ylavic While at it... But this has never bitten us or been noticed, so not necessarily 2.4.24 material.
Re: svn commit: r1774525 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 10:32 PM, wrote: > Author: jim > Date: Thu Dec 15 21:32:50 2016 > New Revision: 1774525 > > URL: http://svn.apache.org/viewvc?rev=1774525&view=rev > Log: > kill the keepalive conns as early as possible during graceful > process exit. > > Modified: > httpd/httpd/trunk/server/mpm/event/event.c > > Modified: httpd/httpd/trunk/server/mpm/event/event.c > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1774525&r1=1774524&r2=1774525&view=diff > == > --- httpd/httpd/trunk/server/mpm/event/event.c (original) > +++ httpd/httpd/trunk/server/mpm/event/event.c Thu Dec 15 21:32:50 2016 > @@ -1865,6 +1865,7 @@ static void * APR_THREAD_FUNC listener_t > if (terminate_mode == ST_UNGRACEFUL > || apr_atomic_read32(&connection_count) == 0) > break; > +process_keepalive_queue(0); /* kill'em all early \m/ */ We need locking here (timeout_mutex). Also on current 2.4.x process_keepalive_queue() does not exist, so for an eventual backport it would be: +process_timeout_queue(keepalive_q, 0, + start_lingering_close_nonblocking); > } But as said there, I don't think it's necessary (and locking may be an overhead while waiting for active conns to terminate, dunno).
Re: T&R of 2.4.24
On Thu, Dec 15, 2016 at 10:52 PM, Yann Ylavic wrote: > On Thu, Dec 15, 2016 at 10:34 PM, Jim Jagielski wrote: >> Done and done. > > Will voted it I meant "will vote" in this typo, not veto ;) Maybe Eric with an easy reproducer could confirm, but unless poll() consistently return EINTR I don't see how his issue can happen on 2.4.24 (after 100ms from the signal to stop/restart).
Re: T&R of 2.4.24
On Thu, Dec 15, 2016 at 10:34 PM, Jim Jagielski wrote: > Done and done. Will voted it, but I don't think it's necessary for 2.4.24 (not harmful though, possibly useless). > >> On Dec 15, 2016, at 4:30 PM, Jim Jagielski wrote: >> >> Actually, it is: >> >>https://svn.apache.org/viewvc?view=revision&revision=1772334 The wakeup changes mentioned by Eric are in r1762718 and follow ups, not backported yet. In 2.4.24 we won't block indefinitely in poll() in any case, hence the keepalive cleanup should always be called on restart/shutdown anyway (every TIMEOUT_FUDGE_FACTOR).
Re: T&R of 2.4.24
I'll give it until tomorrow AM... If we have the 3, it'll be folded in. If not, I'm not going to delay. > On Dec 15, 2016, at 4:34 PM, Jim Jagielski wrote: > > Done and done. > >> On Dec 15, 2016, at 4:30 PM, Jim Jagielski wrote: >> >> Actually, it is: >> >> https://svn.apache.org/viewvc?view=revision&revision=1772334 >> >> So I would like to see the enhancement in: >> >> >> https://lists.apache.org/thread.html/03a360e5214052b38752d10a75f864e59d518cd6ac8ddbbcefe91c18@%3Cdev.httpd.apache.org%3E >> >> applied to trunk and then proposed for backport. >> >>> On Dec 15, 2016, at 2:55 PM, Eric Covener wrote: >>> >>> On Thu, Dec 15, 2016 at 2:09 PM, Eric Covener wrote: On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: >> From what I can see, there are no show-stoppers and >> all my tests show no regressions... >> >> Let's shoot for a T&R this (east coast) evening... how does >> that sound? > > > +1 & thanks Sorry to be a buzzkill but I just replied to an April commit related to PR53555 that I'd like some of the resident big brains to consider as it will be new. But I guess it can be done in parallel with the vote since we have been delayed so much and it's got a fair chance to be no worse than 2.4.23. I do not think it is a showstopper but I see a little smoke there that e.g. ylavic or sf may be able to debunk or throw up a bigger flag on. >>> >>> Yann pointed out that the wakeup enhancement is not in 2.4.x so there >>> is no 2.4.x risk here. >>> >>> -- >>> Eric Covener >>> cove...@gmail.com >> >
Re: T&R of 2.4.24
Done and done. > On Dec 15, 2016, at 4:30 PM, Jim Jagielski wrote: > > Actually, it is: > >https://svn.apache.org/viewvc?view=revision&revision=1772334 > > So I would like to see the enhancement in: > > > https://lists.apache.org/thread.html/03a360e5214052b38752d10a75f864e59d518cd6ac8ddbbcefe91c18@%3Cdev.httpd.apache.org%3E > > applied to trunk and then proposed for backport. > >> On Dec 15, 2016, at 2:55 PM, Eric Covener wrote: >> >> On Thu, Dec 15, 2016 at 2:09 PM, Eric Covener wrote: >>> On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: > From what I can see, there are no show-stoppers and > all my tests show no regressions... > > Let's shoot for a T&R this (east coast) evening... how does > that sound? +1 & thanks >>> >>> Sorry to be a buzzkill but I just replied to an April commit related >>> to PR53555 that I'd like some of the resident big brains to consider >>> as it will be new. >>> >>> But I guess it can be done in parallel with the vote since we have >>> been delayed so much and it's got a fair chance to be no worse than >>> 2.4.23. >>> >>> I do not think it is a showstopper but I see a little smoke there that >>> e.g. ylavic or sf may be able to debunk or throw up a bigger flag on. >>> >> >> Yann pointed out that the wakeup enhancement is not in 2.4.x so there >> is no 2.4.x risk here. >> >> -- >> Eric Covener >> cove...@gmail.com >
Re: T&R of 2.4.24
Actually, it is: https://svn.apache.org/viewvc?view=revision&revision=1772334 So I would like to see the enhancement in: https://lists.apache.org/thread.html/03a360e5214052b38752d10a75f864e59d518cd6ac8ddbbcefe91c18@%3Cdev.httpd.apache.org%3E applied to trunk and then proposed for backport. > On Dec 15, 2016, at 2:55 PM, Eric Covener wrote: > > On Thu, Dec 15, 2016 at 2:09 PM, Eric Covener wrote: >> On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: >>> On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: From what I can see, there are no show-stoppers and all my tests show no regressions... Let's shoot for a T&R this (east coast) evening... how does that sound? >>> >>> >>> +1 & thanks >> >> Sorry to be a buzzkill but I just replied to an April commit related >> to PR53555 that I'd like some of the resident big brains to consider >> as it will be new. >> >> But I guess it can be done in parallel with the vote since we have >> been delayed so much and it's got a fair chance to be no worse than >> 2.4.23. >> >> I do not think it is a showstopper but I see a little smoke there that >> e.g. ylavic or sf may be able to debunk or throw up a bigger flag on. >> > > Yann pointed out that the wakeup enhancement is not in 2.4.x so there > is no 2.4.x risk here. > > -- > Eric Covener > cove...@gmail.com
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
Actually, it is. https://svn.apache.org/viewvc?view=revision&revision=1772334 > On Dec 15, 2016, at 2:47 PM, Yann Ylavic wrote: > > On Thu, Dec 15, 2016 at 8:06 PM, Eric Covener wrote: >> I have been looking at this area a little bit from the perspective of >> killing the keepalive conns as early as possible during graceful >> process exit. >> >> This might have had a bad interaction with the event wakeup patch >> here. > > Hmm, the wakeup patch isn't in 2.4.24/x already no? (not proposed, by > me at least, too much changes in events already...). > >> Now we can sit in poll() for significant time after graceful >> shutdown is signaled (immediately after the poll call that will be >> EINTR'ed). This will happen before the keepalive conns are moved to >> lingering close. >> >> I am not completely sure how 2.4.23 and 2.4.24 will differ here in >> practice but that is also a concern. I think something nearly as >> simple as copying the 2nd block with >> >>process_keepalive_queue(0); /* kill'em all \m/ */ >> >> Into the block where poll returned EINTR may be close to what we need. >> Another unexplored option might be to refer to short poll intervals >> during shutdown, from the perspective of how these two features are >> disturbing eachother. > > If we want to kill keepalive connections early on restart/shutdown I'd rather > : > > Index: server/mpm/event/event.c > === > --- server/mpm/event/event.c(revision 1774260) > +++ server/mpm/event/event.c(working copy) > @@ -1865,6 +1865,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_ > if (terminate_mode == ST_UNGRACEFUL > || apr_atomic_read32(&connection_count) == 0) > break; > +process_keepalive_queue(0); /* kill'em all \m/ */ > } > > if (conns_this_child <= 0) > _ > > so that we don't trigger it on any possible poll() EINTR. > > Does it work for you?
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 3:15 PM, Yann Ylavic wrote: > Ah ok, so you did not reproduced this with vanilla 2.4.x, right? Right, I was on trunk and had just assumed this was backported (I knew the sf stuff was). > > BTW, I had issues while testing both sf's changes (now in 2.4.x), the > wakeup ones and REUSEPORT altogether, with heavy requests/gracefuls > scenario. Interesting. I think my very simple case is more the opposite -- low activity in the process during shutdown that is kind of degenerate.
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 8:54 PM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 2:47 PM, Yann Ylavic wrote: >> Hmm, the wakeup patch isn't in 2.4.24/x already no? (not proposed, by >> me at least, too much changes in events already...). > > > You're right, my bad. I will followup in the release thread that it's > a red herring. Ah ok, so you did not reproduced this with vanilla 2.4.x, right? BTW, I had issues while testing both sf's changes (now in 2.4.x), the wakeup ones and REUSEPORT altogether, with heavy requests/gracefuls scenario. But I couldn't terminate my tests and diagnostic (cleared box by a colleague, and then lack of time). I'll restart these tests as soon as possible, hoping that you found the culprit already ;)
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 3:07 PM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 2:47 PM, Yann Ylavic wrote: >> If we want to kill keepalive connections early on restart/shutdown I'd >> rather : >> >> Index: server/mpm/event/event.c >> === >> --- server/mpm/event/event.c(revision 1774260) >> +++ server/mpm/event/event.c(working copy) >> @@ -1865,6 +1865,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_ >> if (terminate_mode == ST_UNGRACEFUL >> || apr_atomic_read32(&connection_count) == 0) >> break; >> +process_keepalive_queue(0); /* kill'em all \m/ */ >> } >> >> if (conns_this_child <= 0) >> _ >> >> so that we don't trigger it on any possible poll() EINTR. >> >> Does it work for you? > > Seems to do the trick and terminate earlier / makes my temporary > traces more sensible I meant closes the keepalive connections earlier, not terminates the process any earlier!
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 2:47 PM, Yann Ylavic wrote: > If we want to kill keepalive connections early on restart/shutdown I'd rather > : > > Index: server/mpm/event/event.c > === > --- server/mpm/event/event.c(revision 1774260) > +++ server/mpm/event/event.c(working copy) > @@ -1865,6 +1865,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_ > if (terminate_mode == ST_UNGRACEFUL > || apr_atomic_read32(&connection_count) == 0) > break; > +process_keepalive_queue(0); /* kill'em all \m/ */ > } > > if (conns_this_child <= 0) > _ > > so that we don't trigger it on any possible poll() EINTR. > > Does it work for you? Seems to do the trick and terminate earlier / makes my temporary traces more sensible -- Eric Covener cove...@gmail.com
Re: T&R of 2.4.24
On Thu, Dec 15, 2016 at 2:09 PM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: >> On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: >>> From what I can see, there are no show-stoppers and >>> all my tests show no regressions... >>> >>> Let's shoot for a T&R this (east coast) evening... how does >>> that sound? >> >> >> +1 & thanks > > Sorry to be a buzzkill but I just replied to an April commit related > to PR53555 that I'd like some of the resident big brains to consider > as it will be new. > > But I guess it can be done in parallel with the vote since we have > been delayed so much and it's got a fair chance to be no worse than > 2.4.23. > > I do not think it is a showstopper but I see a little smoke there that > e.g. ylavic or sf may be able to debunk or throw up a bigger flag on. > Yann pointed out that the wakeup enhancement is not in 2.4.x so there is no 2.4.x risk here. -- Eric Covener cove...@gmail.com
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 2:47 PM, Yann Ylavic wrote: > Hmm, the wakeup patch isn't in 2.4.24/x already no? (not proposed, by > me at least, too much changes in events already...). You're right, my bad. I will followup in the release thread that it's a red herring. -- Eric Covener cove...@gmail.com
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
On Thu, Dec 15, 2016 at 8:06 PM, Eric Covener wrote: > I have been looking at this area a little bit from the perspective of > killing the keepalive conns as early as possible during graceful > process exit. > > This might have had a bad interaction with the event wakeup patch > here. Hmm, the wakeup patch isn't in 2.4.24/x already no? (not proposed, by me at least, too much changes in events already...). > Now we can sit in poll() for significant time after graceful > shutdown is signaled (immediately after the poll call that will be > EINTR'ed). This will happen before the keepalive conns are moved to > lingering close. > > I am not completely sure how 2.4.23 and 2.4.24 will differ here in > practice but that is also a concern. I think something nearly as > simple as copying the 2nd block with > > process_keepalive_queue(0); /* kill'em all \m/ */ > > Into the block where poll returned EINTR may be close to what we need. > Another unexplored option might be to refer to short poll intervals > during shutdown, from the perspective of how these two features are > disturbing eachother. If we want to kill keepalive connections early on restart/shutdown I'd rather : Index: server/mpm/event/event.c === --- server/mpm/event/event.c(revision 1774260) +++ server/mpm/event/event.c(working copy) @@ -1865,6 +1865,7 @@ static void * APR_THREAD_FUNC listener_thread(apr_ if (terminate_mode == ST_UNGRACEFUL || apr_atomic_read32(&connection_count) == 0) break; +process_keepalive_queue(0); /* kill'em all \m/ */ } if (conns_this_child <= 0) _ so that we don't trigger it on any possible poll() EINTR. Does it work for you?
Re: T&R of 2.4.24
On 12/15/2016 08:09 PM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: >> On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: >>> From what I can see, there are no show-stoppers and >>> all my tests show no regressions... >>> >>> Let's shoot for a T&R this (east coast) evening... how does >>> that sound? >> >> >> +1 & thanks +1 and many thanks from me as well. > > Sorry to be a buzzkill but I just replied to an April commit related > to PR53555 that I'd like some of the resident big brains to consider > as it will be new. Shame on you for being a buzzkill :-). No seriously, thanks for giving a heads up here. Regards Rüdiger
Re: T&R of 2.4.24
On Thu, Dec 15, 2016 at 10:16 AM, Eric Covener wrote: > On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: >> From what I can see, there are no show-stoppers and >> all my tests show no regressions... >> >> Let's shoot for a T&R this (east coast) evening... how does >> that sound? > > > +1 & thanks Sorry to be a buzzkill but I just replied to an April commit related to PR53555 that I'd like some of the resident big brains to consider as it will be new. But I guess it can be done in parallel with the vote since we have been delayed so much and it's got a fair chance to be no worse than 2.4.23. I do not think it is a showstopper but I see a little smoke there that e.g. ylavic or sf may be able to debunk or throw up a bigger flag on. -- Eric Covener cove...@gmail.com
Re: svn commit: r1738464 - /httpd/httpd/trunk/server/mpm/event/event.c
I have been looking at this area a little bit from the perspective of
killing the keepalive conns as early as possible during graceful
process exit.
This might have had a bad interaction with the event wakeup patch
here. Now we can sit in poll() for significant time after graceful
shutdown is signaled (immediately after the poll call that will be
EINTR'ed). This will happen before the keepalive conns are moved to
lingering close.
I am not completely sure how 2.4.23 and 2.4.24 will differ here in
practice but that is also a concern. I think something nearly as
simple as copying the 2nd block with
process_keepalive_queue(0); /* kill'em all \m/ */
Into the block where poll returned EINTR may be close to what we need.
Another unexplored option might be to refer to short poll intervals
during shutdown, from the perspective of how these two features are
disturbing eachother.
On Sun, Apr 10, 2016 at 4:35 PM, wrote:
> Author: sf
> Date: Sun Apr 10 20:35:18 2016
> New Revision: 1738464
>
> URL: http://svn.apache.org/viewvc?rev=1738464&view=rev
> Log:
> Terminate keep-alive connections when dying
>
> When shutting down a process gracefully, terminate keep-alive connections so
> that we don't get any new requests which may keep the dying process alive
> longer.
>
>
> Modified:
> httpd/httpd/trunk/server/mpm/event/event.c
>
> Modified: httpd/httpd/trunk/server/mpm/event/event.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1738464&r1=1738463&r2=1738464&view=diff
> ==
> --- httpd/httpd/trunk/server/mpm/event/event.c (original)
> +++ httpd/httpd/trunk/server/mpm/event/event.c Sun Apr 10 20:35:18 2016
> @@ -2075,11 +2075,12 @@ static void * APR_THREAD_FUNC listener_t
> /* If all workers are busy, we kill older keep-alive connections
> so that they
> * may connect to another process.
> */
> -if (workers_were_busy && *keepalive_q->total) {
> -ap_log_error(APLOG_MARK, APLOG_TRACE1, 0, ap_server_conf,
> - "All workers are busy, will close %d keep-alive
> "
> - "connections",
> - *keepalive_q->total);
> +if ((workers_were_busy || dying) && *keepalive_q->total) {
> +if (!dying)
> +ap_log_error(APLOG_MARK, APLOG_TRACE1, 0, ap_server_conf,
> + "All workers are busy, will close %d
> keep-alive "
> + "connections",
> + *keepalive_q->total);
> process_timeout_queue(keepalive_q, 0,
>start_lingering_close_nonblocking);
> }
>
>
--
Eric Covener
cove...@gmail.com
Re: svn commit: r1774010 - in /httpd/test/framework/trunk/t: conf/extra.conf.in modules/ext_filter.t
On Thu, Dec 15, 2016 at 5:21 AM, Joe Orton wrote: > On Thu, Dec 15, 2016 at 02:05:32AM -0600, William A Rowe Jr wrote: > > Joe, did you forget an svn add? I see no ext_filter/ subdirectory on > trunk; > > > > https://svn.apache.org/repos/asf/httpd/test/framework/ > trunk/t/htdocs/modules/filter/ > > Oops :( Added now, sorry guys. > Confirmed test 2 now passes on 2.4.23, 2.4 branch, trunk. Users should be aware that t/TEST -clean will not pick up this change, 'perl Makefile.PL; make' is needed to provision it.
Re: T&R of 2.4.24
+1 and *many* thanks! > Am 15.12.2016 um 16:13 schrieb Jim Jagielski : > > From what I can see, there are no show-stoppers and > all my tests show no regressions... > > Let's shoot for a T&R this (east coast) evening... how does > that sound? > >> On Dec 14, 2016, at 7:56 AM, Jim Jagielski wrote: >> >> Looking at a T&R of 2.4.24 either the 15th or 16th... > Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
Re: T&R of 2.4.24
On Thu, Dec 15, 2016 at 10:13 AM, Jim Jagielski wrote: > From what I can see, there are no show-stoppers and > all my tests show no regressions... > > Let's shoot for a T&R this (east coast) evening... how does > that sound? +1 & thanks -- Eric Covener cove...@gmail.com
Re: T&R of 2.4.24
From what I can see, there are no show-stoppers and all my tests show no regressions... Let's shoot for a T&R this (east coast) evening... how does that sound? > On Dec 14, 2016, at 7:56 AM, Jim Jagielski wrote: > > Looking at a T&R of 2.4.24 either the 15th or 16th...
Re: AW: svn commit: r1773865 - /httpd/httpd/trunk/modules/http/http_filters.c
2016-12-14 18:53 GMT+01:00 Jacob Champion : > On 12/14/2016 09:33 AM, Jacob Champion wrote: > >> The current public filter documentation at [1] (which is old, but still >> the only overall documentation I'm aware of) says >> > > Forgot the link, sorry. > > [1] https://httpd.apache.org/docs/trunk/developer/output-filters.html +1, it would be really great to have more bucket-related documentation for newcomers like me, it would help a lot to bootstrap committers in the right way :) Thanks! Luca
Re: svn commit: r1774010 - in /httpd/test/framework/trunk/t: conf/extra.conf.in modules/ext_filter.t
On Thu, Dec 15, 2016 at 02:05:32AM -0600, William A Rowe Jr wrote: > Joe, did you forget an svn add? I see no ext_filter/ subdirectory on trunk; > > https://svn.apache.org/repos/asf/httpd/test/framework/trunk/t/htdocs/modules/filter/ Oops :( Added now, sorry guys.
AW: svn commit: r1773865 - /httpd/httpd/trunk/modules/http/http_filters.c
> -Ursprüngliche Nachricht- > Von: Yann Ylavic [mailto:ylavic@gmail.com] > Gesendet: Mittwoch, 14. Dezember 2016 19:58 > An: httpd-dev > Betreff: Re: svn commit: r1773865 - > /httpd/httpd/trunk/modules/http/http_filters.c > > On Wed, Dec 14, 2016 at 9:45 AM, Plüm, Rüdiger, Vodafone Group > wrote: > > > >> -Ursprüngliche Nachricht- > >> Von: Yann Ylavic [mailto:ylavic@gmail.com] > >> Gesendet: Mittwoch, 14. Dezember 2016 01:42 > > >> > >> For the EOC case, how about: > > > > Looks good apart that I wouldn't do the break in the EOS case to catch > EOC buckets after the EOS. > > Applied in r1774286 (and proposed for backport, 2.4.24?). Thanks. Just voted. So only one more vote missing. > > No hurry about the new (attached) patch however, only an improvement > IMHO. New one looks good. Happy to see this in trunk. Regards Rüdiger
Re: Making test framework and trunk approachable (was: PCRE 10 and puzzling edge cases)
On Mon, Dec 12, 2016 at 01:03:23PM -0600, William A Rowe Jr wrote: > System APR does require the -devel package. That RHEL package aught to > install the .m4 logic required by httpd, but it is on us to find that in a > conventional place. > I think this should be handled in the buildconf script. The apr-devel package puts find_apr.m4 into /usr/share/aclocal (check "aclocal --print-ac-dir" output). > Httpd trunk is already hunting for yet unreleased APR 1.6 features, but we > should better document that. > That can happen. Then there is nothing to improve. > Not yet installed httpd is a little more complex, maybe we can add an > interim apxs in the build tree to facilitate this? > Something like libtool allows to run executables linked to just-built libraries. Maybe. But I think the hardest issue is the modules sources are scattered across many directories and the just-built module DSOs too. Tests should have to be smarter in locating them. -- Petr signature.asc Description: PGP signature
Re: svn commit: r1774010 - in /httpd/test/framework/trunk/t: conf/extra.conf.in modules/ext_filter.t
On Wed, Dec 14, 2016 at 11:30 PM, William A Rowe Jr wrote: > On Wed, Dec 14, 2016 at 2:51 AM, Joe Orton wrote: > >> >> I adjusted the test case to cope with a sed which adds a trailing >> newline now, does that pass with OS X sed? I'm yet to work out why the >> test cases passes in trunk and fails in 2.4, mod_ext_filter is the same >> in both branches. >> > > Seeing different issues on Fedora 24 under 2.x and 2.4 branches > On 2.4 branch, everything seems to go sideways; > > t/modules/ext_filter.t .. 1/24 > # Failed test 2 in t/modules/ext_filter.t at line 26 > # Failed test 5 in t/modules/ext_filter.t at line 36 > # Failed test 6 in t/modules/ext_filter.t at line 37 > # Failed test 7 in t/modules/ext_filter.t at line 36 fail #2 > # Failed test 8 in t/modules/ext_filter.t at line 37 fail #2 > # Failed test 9 in t/modules/ext_filter.t at line 36 fail #3 > # Failed test 10 in t/modules/ext_filter.t at line 37 fail #3 > # Failed test 11 in t/modules/ext_filter.t at line 36 fail #4 > # Failed test 12 in t/modules/ext_filter.t at line 37 fail #4 > # Failed test 13 in t/modules/ext_filter.t at line 36 fail #5 > # Failed test 14 in t/modules/ext_filter.t at line 37 fail #5 > # Failed test 15 in t/modules/ext_filter.t at line 36 fail #6 > # Failed test 16 in t/modules/ext_filter.t at line 37 fail #6 > # Failed test 17 in t/modules/ext_filter.t at line 36 fail #7 > # Failed test 18 in t/modules/ext_filter.t at line 37 fail #7 > # Failed test 19 in t/modules/ext_filter.t at line 36 fail #8 > # Failed test 20 in t/modules/ext_filter.t at line 37 fail #8 > # Failed test 21 in t/modules/ext_filter.t at line 36 fail #9 > # Failed test 22 in t/modules/ext_filter.t at line 37 fail #9 > # Failed test 23 in t/modules/ext_filter.t at line 36 fail #10 > # Failed test 24 in t/modules/ext_filter.t at line 37 fail #10 > t/modules/ext_filter.t .. Failed 21/24 subtests > > I don't see anything else wrong on 2.4 branch except for > > t/modules/rewrite.t . 1/34 # Failed test 34 in > t/modules/rewrite.t at line 120 > t/modules/rewrite.t . Failed 1/34 subtests > (1 TODO test unexpectedly succeeded) > > But I have not yet caught up with the latest commits to rewrite. > > Thinking that on 2.4 branch, a poorly performing retest against 2.4.23 > is all that is needed to proceed to release, and then return to address > later as not-a-regression. > On 2.3.23, indeed this doesn't look like a regression (test 2 again fails on the missing perl script); t/modules/ext_filter.t .. 1/24 # Failed test 2 in t/modules/ext_filter.t at line 26 # Failed test 5 in t/modules/ext_filter.t at line 36 # Failed test 6 in t/modules/ext_filter.t at line 37 # Failed test 7 in t/modules/ext_filter.t at line 36 fail #2 # Failed test 8 in t/modules/ext_filter.t at line 37 fail #2 # Failed test 9 in t/modules/ext_filter.t at line 36 fail #3 # Failed test 10 in t/modules/ext_filter.t at line 37 fail #3 # Failed test 11 in t/modules/ext_filter.t at line 36 fail #4 # Failed test 12 in t/modules/ext_filter.t at line 37 fail #4 # Failed test 13 in t/modules/ext_filter.t at line 36 fail #5 # Failed test 14 in t/modules/ext_filter.t at line 37 fail #5 # Failed test 15 in t/modules/ext_filter.t at line 36 fail #6 # Failed test 16 in t/modules/ext_filter.t at line 37 fail #6 # Failed test 17 in t/modules/ext_filter.t at line 36 fail #7 # Failed test 18 in t/modules/ext_filter.t at line 37 fail #7 # Failed test 19 in t/modules/ext_filter.t at line 36 fail #8 # Failed test 20 in t/modules/ext_filter.t at line 37 fail #8 # Failed test 21 in t/modules/ext_filter.t at line 36 fail #9 # Failed test 22 in t/modules/ext_filter.t at line 37 fail #9 # Failed test 23 in t/modules/ext_filter.t at line 36 fail #10 # Failed test 24 in t/modules/ext_filter.t at line 37 fail #10 t/modules/ext_filter.t .. Failed 21/24 subtests I'd think we are fine to proceed to 2.4.24 tag, this isn't a regression.
Re: svn commit: r1774010 - in /httpd/test/framework/trunk/t: conf/extra.conf.in modules/ext_filter.t
On Wed, Dec 14, 2016 at 11:30 PM, William A Rowe Jr wrote: > On Wed, Dec 14, 2016 at 2:51 AM, Joe Orton wrote: > >> >> I adjusted the test case to cope with a sed which adds a trailing >> newline now, does that pass with OS X sed? I'm yet to work out why the >> test cases passes in trunk and fails in 2.4, mod_ext_filter is the same >> in both branches. >> > > Seeing different issues on Fedora 24 under 2.x and 2.4 branches, neither > seems entirely good, 2.4 is especially strange. > > On 2.x branch, Test #2 fails with a failed to create process. > > [Thu Dec 15 05:07:21.578683 2016] [ext_filter:error] [pid 19326:tid > 139620838786816] (2)No such file or directory: [client 127.0.0.1:49186] > AH01458: couldn't create child process to run `/home/wrowe/dev/test/test2x- > apr20-ossl110/t/htdocs/modules/ext_filter/sleepycat.pl' > Joe, did you forget an svn add? I see no ext_filter/ subdirectory on trunk; https://svn.apache.org/repos/asf/httpd/test/framework/trunk/t/htdocs/modules/filter/
