Hi guys,

On Tue, Sep 18, 2018 at 11:54:59AM +0200, Lukas Tribus wrote:
> Hi Manu,
> 
> 
> On Fri, 14 Sep 2018 at 15:45, Emmanuel Hocdet <[email protected]> wrote:
> >
> > Hi,
> >
> > Quick test with 1.9-dev2, and i see latency (in seconds) to connect to 
> > haproxy with SSL (tcp mode).
> > It's ok in master with 9f9b0c6a.
> > No time to investigate more for the moment.
> 
> I cannot reproduce it in a simple SSL termination + tcp mode
> configuration. There is probably something more to it.

We definitely have some issues related to connection setup and tear down
that we're investigating. They're all related to the changes consisting
in orienting the recv/send calls from up to down and not relying on waking
up everything bottom-to-top.

There's a very closely related issue that Pieter reported with TCP
connections without data causing issues, another one that Christopher
just faced this morning where connection errors wake up process_stream()
in loops, and some cases where client errors on H2 can crash the process.

I'm sorry for all these issues, but having the code merged as a first
step was the only option to make forward progress on this part. Having
everyone constantly rebase his own code on hypothetic changes was not
workable anymore.

Among the possible solutions currently being studied, it seems that there
are too many places where the "process" part of the mux is called instead
of being scheduled (typically the cases where we update the polling). But
this is still under investigation.

Thus if you're still finishing your devs for 1.9, 1.9-dev2 gives a preview
of the forthcoming changes that will apply to the connection layers, at the
price of accepting to work around the current limitations. If you want
something to play with on your own servers, it definitely isn't something
to play with.

I'm currently trying to stabilize this so that we can at least continue
the development with less disturbance, but it's really not easy, as this
merge has at least uncovered some limitations of the current model among
those inherited from the prehistoric code :-/

Thanks,
Willy

Reply via email to