Re: about those async filters

2015-10-09 Thread Jim Jagielski
> On Oct 8, 2015, at 7:59 AM, Graham Leggett wrote: > > On 08 Oct 2015, at 1:45 PM, Jim Jagielski wrote: > >> Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide >> useful clues on how to make 2.6/3.0 better, especially w/ the idea of >>

Re: about those async filters

2015-10-08 Thread Stefan Eissing
OK, found the bug. Seems an update to the lastest nghttp2 lib co-incided with the checkin of your async filter changes. Everything is fine now. At least I learned some more about core filters, cannot hurt. Thanks for the help. //Stefan > Am 07.10.2015 um 18:40 schrieb Graham Leggett

Re: about those async filters

2015-10-08 Thread Graham Leggett
On 07 Oct 2015, at 4:30 PM, Stefan Eissing wrote: > In http2 land, the request happen on "pseudo" connections, connections > properly created by ap_run_create_connection(), but with own filters of type > AP_FTYPE_PROTOCOL and AP_FTYPE_NETWORK, registered by

Re: about those async filters

2015-10-08 Thread Graham Leggett
On 08 Oct 2015, at 1:45 PM, Jim Jagielski wrote: > Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide > useful clues on how to make 2.6/3.0 better, especially w/ the idea of > slave connections; basically, as you say, let the MPM make mod_http2's > job easier

Re: about those async filters

2015-10-08 Thread Stefan Eissing
Graham, I am very happy to get such feedback and start thinking about how to make the http/2 integration tighter. As it is designed now, it was intended to fit into a 2.4.x server which limited several design decisions and resulted in the separate worker pool. Since HTTP/2 changes the

Re: about those async filters

2015-10-08 Thread Stefan Eissing
> Am 08.10.2015 um 13:53 schrieb Graham Leggett : > >> HTTP/2 on https:// connections, as reported by Firefox, is currently at ~30% >> of requests. > > We need to make sure we haven’t made a step backwards in the core of the > server. The event MPM solved the C10k problem

Re: about those async filters

2015-10-08 Thread Graham Leggett
On 08 Oct 2015, at 1:23 PM, Stefan Eissing wrote: > I am very happy to get such feedback and start thinking about how to make the > http/2 integration tighter. As it is designed now, it was intended to fit > into a 2.4.x server which limited several design

Re: about those async filters

2015-10-08 Thread Jim Jagielski
Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide useful clues on how to make 2.6/3.0 better, especially w/ the idea of slave connections; basically, as you say, let the MPM make mod_http2's job easier by abstracting out a lot of the tricks that mod_http2 needs to do to

Re: about those async filters

2015-10-07 Thread Graham Leggett
On 07 Oct 2015, at 3:43 PM, Stefan Eissing wrote: > Having just had time to look at which test cases fail: I see that static > resources via HTTP/2 seem to work fine, however my tests with a proxy and or > rewrite in between fail with high likelihood. > > Any

about those async filters

2015-10-07 Thread Stefan Eissing
Having just had time to look at which test cases fail: I see that static resources via HTTP/2 seem to work fine, however my tests with a proxy and or rewrite in between fail with high likelihood. Any hint at what exactly I might have to look for, any hint about what actually has changed,

Re: about those async filters

2015-10-07 Thread Yann Ylavic
Hi Stefan, On Wed, Oct 7, 2015 at 3:43 PM, Stefan Eissing wrote: > Having just had time to look at which test cases fail: I see that static > resources via HTTP/2 seem to work fine, however my tests with a proxy and or > rewrite in between fail with high

Re: about those async filters

2015-10-07 Thread Stefan Eissing
> Am 07.10.2015 um 16:09 schrieb Graham Leggett : > > On 07 Oct 2015, at 3:43 PM, Stefan Eissing > wrote: > >> Having just had time to look at which test cases fail: I see that static >> resources via HTTP/2 seem to work fine, however my tests

Re: about those async filters

2015-10-07 Thread Stefan Eissing
> Am 07.10.2015 um 17:55 schrieb Graham Leggett : > > On 07 Oct 2015, at 4:30 PM, Stefan Eissing > wrote: >> [...] >> Due to the non-multithreadability of apr_buckets, no buckets are ever moved >> across threads. non-meta buckets are read, meta

Re: about those async filters

2015-10-07 Thread Graham Leggett
On 07 Oct 2015, at 4:30 PM, Stefan Eissing wrote: >> Can you describe how cleanups occur in the http2 world? > > In http2 land, the request happen on "pseudo" connections, connections > properly created by ap_run_create_connection(), but with own filters of type

Re: about those async filters

2015-10-07 Thread Graham Leggett
On 07 Oct 2015, at 6:23 PM, Stefan Eissing wrote: >> Can you explain "non-multithreadability of apr_buckets” in more detail? I >> take it this is the problem with passing a bucket from one allocator to >> another? >> >> If so then the copy makes more sense. > >