Re: Re: Test failure on 2.4-HEAD

2014-08-26 Thread Eric Covener
On Tue, Aug 26, 2014 at 5:01 PM, wrote: > I presume the 3 +1's were sufficient? There was some discussion > around the change hitting 2.2 before 2.4, so I wanted to be sure we > had the right patch on the actively maintained release branch, at > least in svn. No issues, I just misremembered the

RE: [VOTE] Release 2.2.28 as GA?

2014-08-26 Thread wrowe
- Original Message - Subject: RE: [VOTE] Release 2.2.28 as GA? From: wr...@rowe-clan.net Date: 8/26/14 4:07 pm To: dev@httpd.apache.org Glad to see the testing efforts, it looks like this is going to fly. Jumped over from *nix-ish platforms back into Windows for a while, so I'll m

RE: [VOTE] Release 2.2.28 as GA?

2014-08-26 Thread wrowe
Glad to see the testing efforts, it looks like this is going to fly. Jumped over from *nix-ish platforms back into Windows for a while, so I'll make sure the -win32-src.zip is collected with a successful binary build against openssl 1.0.1i this aftn/eve, and sum the votes provided there is no sur

RE: Re: Test failure on 2.4-HEAD

2014-08-26 Thread wrowe
- Original Message - Subject: Re: Test failure on 2.4-HEAD From: "Jim Jagielski" Date: 8/26/14 11:20 am To: dev@httpd.apache.org On Aug 26, 2014, at 11:02 AM, Eric Covener wrote: > I recognize it, it's what you get if you built the (proposed only?) > trailers thing Looks li

Re: Test failure on 2.4-HEAD

2014-08-26 Thread Eric Covener
On Tue, Aug 26, 2014 at 1:18 PM, Eric Covener wrote: > On Tue, Aug 26, 2014 at 12:20 PM, Jim Jagielski wrote: >> Looks like its been folded into 2.4-branch... > > Sorry you are right. I will fix the TC r1620663.

Re: Test failure on 2.4-HEAD

2014-08-26 Thread Eric Covener
On Tue, Aug 26, 2014 at 12:20 PM, Jim Jagielski wrote: > Looks like its been folded into 2.4-branch... Sorry you are right. I will fix the TC -- Eric Covener cove...@gmail.com

Re: Test failure on 2.4-HEAD

2014-08-26 Thread Jim Jagielski
On Aug 26, 2014, at 11:02 AM, Eric Covener wrote: > I recognize it, it's what you get if you built the (proposed only?) > trailers thing Looks like its been folded into 2.4-branch...

Re: Test failure on 2.4-HEAD

2014-08-26 Thread Rainer Jung
Am 26.08.2014 um 17:02 schrieb Eric Covener: On Tue, Aug 26, 2014 at 10:51 AM, Jim Jagielski wrote: Anyone else seeing this with HEAD of 2.4? # testing : trailer (pid) # expected: '67568' # received: 'No chunked trailer available!' not ok 3 # Failed test 3 in t/apache/chunkinput.t at line 71

Re: Test failure on 2.4-HEAD

2014-08-26 Thread Eric Covener
On Tue, Aug 26, 2014 at 10:51 AM, Jim Jagielski wrote: > Anyone else seeing this with HEAD of 2.4? > > # testing : trailer (pid) > # expected: '67568' > # received: 'No chunked trailer available!' > not ok 3 > # Failed test 3 in t/apache/chunkinput.t at line 71 I recognize it, it's what you get

Test failure on 2.4-HEAD

2014-08-26 Thread Jim Jagielski
Anyone else seeing this with HEAD of 2.4? # testing : trailer (pid) # expected: '67568' # received: 'No chunked trailer available!' not ok 3 # Failed test 3 in t/apache/chunkinput.t at line 71

Re: svn commit: r1599531 - in /httpd/httpd/trunk: CHANGES include/ap_listen.h server/listen.c server/mpm/event/event.c server/mpm/prefork/prefork.c server/mpm/worker/worker.c server/mpm_unix.c

2014-08-26 Thread Jan Kaluža
On 08/19/2014 12:39 PM, Jan Kaluža wrote: @@ -3206,6 +3277,10 @@ static int event_pre_config(apr_pool_t * "atomics not working as expected - add32 of negative number"); return HTTP_INTERNAL_SERVER_ERROR; } +retained->idle_spawn_rate = apr_pa

Re: PR56729: reqtimeout bug with fast response and slow POST

2014-08-26 Thread Eric Covener
On Mon, Aug 25, 2014 at 4:05 PM, Eric Covener wrote: > I am looking at this PR which I was able to recreate: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=56729 Whoops, I got the topic backwards. Fast post, slow response. -- Eric Covener cove...@gmail.com

Re: PR56729: reqtimeout bug with fast response and slow POST

2014-08-26 Thread Yann Ylavic
On Mon, Aug 25, 2014 at 10:05 PM, Eric Covener wrote: > But it seemed a little hokey, but I didn't really understand if we > could instead treat that speculative read as some kind of reset point > and couldn't think of any other hook to tell reqtimeout to bail out. > > Any alternatives? I don't t