Hi, i'm happy to confirm the two patches combined address the symptom I reported at the start of the thread. I applied them to haproxy.git master after confirming that the problem occurred there for a realistic setup (couchdb with HAProxy in front configured to do compression).
The CouchDB project are considering adding a WebSocket option for this endpoint in light of the re-realisation that we've been living in HTTP sin this whole time. Your patches are most welcome as they mean users can keep doing what they've always been doing and can upgrade HAProxy without having to make any change. In the long term CouchDB will work towards providing an alternative method that doesn't depend on the timely delivery of partial messages. Thank you again for your efforts, it is very much appreciated. B. > On 26 Jun 2023, at 18:50, Willy Tarreau <[email protected]> wrote: > > Hi Robert, > > On Sat, Jun 24, 2023 at 09:48:31PM +0100, Robert Newson wrote: >> Hi, >> >> That sounds great, much appreciated. I'll be available all week to test any >> patches you might propose. > > I gave it a try. There was already a flush call in the data block > processing (I don't know why, to be honest, I'd rather condition it to > the low latency, but let's not mix things for now). So I implemented a > flush() operation for slz and added a call to it in haproxy. > > I'd be interested if you could test the two attached patches. They're > for 2.9-dev but will likely apply to 2.8 and probably even a number of > older releases since this part doesn't change often. My tests were > fairly limited, I just verified that compressing a large file (200 MB) > directly with slz while injecting flushes after each read() continues > to produce the valid data, and that the regtests are still OK (a few > of them do use the compression). > > Thanks, > Willy > <0001-IMPORT-slz-implement-a-synchronous-flush-operation.patch><0002-WIP-compression-slz-support-just-a-pure-flush.patch>
