Hi Lukas, On Wed, Nov 01, 2017 at 09:02:53PM +0100, Willy Tarreau wrote: > Hi Lukas, > > On Wed, Nov 01, 2017 at 08:43:19PM +0100, Lukas Tribus wrote: > > Just upgrading the binary from -dev3 to -rc1 however broke my setup: > > Turns out that the new object caching code breaks when another filter > > (compression) is already enabled (at config parsing stage) - even when > > object caching is not enabled itself: > > > (...) > > > > lukas@dev:~/haproxy$ ./haproxy -f ../haproxy.cfg > > [ALERT] 304/203750 (6995) : Proxy 'http_in': unable to find the cache > > '(null)' referenced by the filter 'cache'. > > [ALERT] 304/203750 (6995) : Proxy 'bk_testbk': unable to find the > > cache '(null)' referenced by the filter 'cache'. > > [ALERT] 304/203750 (6995) : Fatal errors found in configuration. > > lukas@dev:~/haproxy$ > > > > Now I'm going to disable compression and try the fun stuff :) >
That's a bug of the post parsing callback, it tries to use the cache with a filter which is not a cache. I just fix it in the master. > Thanks for reporting, such type of early breakage is indeed expected > after I stressed everyone to merge. We know that the inned parts work > pretty well overall but some integration work is now needed. > > You may have to explicitly use the compression filter by the way, > though I have no idea how to do that but I think it's mentionned > somewhere in the config manual. William was about to write some doc > when I interrupted him to get his code, but he'll certainly get back > to this soon. It will need a configuration filter keyword for the cache, to define the explicit order of the filters. The cache might not work after the compression in the current state of the filter API. -- William Lallemand
