Re: A few comments on mod_proxy_hc

2016-01-22 Thread Jim Jagielski
> On Jan 22, 2016, at 3:55 PM, Christophe JAILLET > wrote: > > Hi, > > My 2 cents on mod_proxy_hc: > > > 1) around line 278: > > I think that a: >template->hcexpr = NULL; > is missing. > Thx. > > > 2) line 363 >r->protocol = (char*)"HTTP/1.1"; > This is just fine for me, but r-

A few comments on mod_proxy_hc

2016-01-22 Thread Christophe JAILLET
Hi, My 2 cents on mod_proxy_hc: 1) around line 278: I think that a: template->hcexpr = NULL; is missing. 2) line 363 r->protocol = (char*)"HTTP/1.1"; This is just fine for me, but r->protocol is not const. Other places uses apr_pstrdup for that. (around line 617 and 637 of protocol

Re: Work in progress: mod_proxy Health Check module

2016-01-22 Thread Jim Jagielski
I had some cycles before the snow hit so added usage of threadpools, so that the checks are done in parallel rather than series... Quick impl. > On Jan 22, 2016, at 12:36 PM, Yann Ylavic wrote: > > On Fri, Jan 22, 2016 at 6:29 PM, Jim Jagielski wrote: >> At this point GET is now implemented as

Re: ap_init_rng / apr_random question

2016-01-22 Thread Eric Covener
Maybe another topic for 1.6. Is it wise to keep this code around? On Sun, Nov 1, 2015 at 10:20 AM, Eric Covener wrote: > On Tue, Oct 27, 2015 at 8:00 PM, Yann Ylavic wrote: >> On Tue, Oct 27, 2015 at 6:57 PM, Eric Covener wrote: >>> IIUC, it takes something like 32k of /dev/random to initialize

Re: Work in progress: mod_proxy Health Check module

2016-01-22 Thread Yann Ylavic
On Fri, Jan 22, 2016 at 6:29 PM, Jim Jagielski wrote: > At this point GET is now implemented as well as checking > the response via ap_expr... Thanks Jim, this is great!

Re: Work in progress: mod_proxy Health Check module

2016-01-22 Thread Jim Jagielski
At this point GET is now implemented as well as checking the response via ap_expr... I think this is at a stage to let it sit for a bit and have people whack away at it. I have some ideas on extending it to use a thread-pool in the watchdog, to allow for parallel health-checks. Eventually, using

Re: async keepalive in http/2

2016-01-22 Thread Stefan Eissing
First experiments show that event does not always call ap_start_lingering_close(c) and exactly for the interesting cases. As I read it, the reason is that ap_start_lingering_close() does a flush on the connection and event wants to start lingering close when shifting the connection from its kee

Re: async keepalive in http/2

2016-01-22 Thread Jim Jagielski
+1 > On Jan 22, 2016, at 9:17 AM, Stefan Eissing > wrote: > > >> Am 22.01.2016 um 15:16 schrieb Eric Covener : >> >> On Fri, Jan 22, 2016 at 9:12 AM, Stefan Eissing >> wrote: >>> With the timeout behaviour of SSL reads fixed, I am making another attempt >>> at have http/2 connections behave

Re: async keepalive in http/2

2016-01-22 Thread Stefan Eissing
> Am 22.01.2016 um 15:16 schrieb Eric Covener : > > On Fri, Jan 22, 2016 at 9:12 AM, Stefan Eissing > wrote: >> With the timeout behaviour of SSL reads fixed, I am making another attempt >> at have http/2 connections behave properly in async MPMs, e.g. event. One >> thing for that necessary as

Re: async keepalive in http/2

2016-01-22 Thread Eric Covener
On Fri, Jan 22, 2016 at 9:12 AM, Stefan Eissing wrote: > With the timeout behaviour of SSL reads fixed, I am making another attempt at > have http/2 connections behave properly in async MPMs, e.g. event. One thing > for that necessary as change in server is the hook to send a last GOAWAY > fram

async keepalive in http/2

2016-01-22 Thread Stefan Eissing
With the timeout behaviour of SSL reads fixed, I am making another attempt at have http/2 connections behave properly in async MPMs, e.g. event. One thing for that necessary as change in server is the hook to send a last GOAWAY frame before the connection is closed. Not sending it seems to confu