On Wed, Jun 08, 2011 at 10:55:44AM +0200, Willy Tarreau wrote: > On Wed, Jun 08, 2011 at 05:00:44PM +0900, Simon Horman wrote: > > I'm happy with documenting things as you suggest. > > Fine. > > > Do you have any feeling of how difficult it would be > > to add a per-server session list? > > Not particularly difficult, we just need to add a struct list member > into the session and use it to chain sessions behind their servers. > We also need to ensure that each time we redispatch, we move this. > Probably that we should have a list head in the backend so that sessions > that are not yet on a server should be chained somewhere. > > > > Another point is that a flapping server can definitely make a service > > > totally unusable and that must be indicated too. You can check any stats > (...) > > I considered that too. My idea was that perhaps connections should only be > > closed when they receive their next packet. That is, when a read is made > > from the client for a session whose server is down. > > No, this will not cover most users' needs. Most of the times, the issues was > to quickly notify the client that the server is dead so that the client does > not have to wait for a timeout or for activity to be aware of it. > > > But it it seems to me that there demand for the feature I have implemented > > (modulo bugs and performance issues). And that alternative schemes such as > > the one I describe above could be separate on-markeddown actions. > > I really don't think it will be that much useful anyway. So yes, if there is > demand that makes sense, a separate action can be added. > > > > Well, maybe we should still consider the possibility that we only kill the > > > connection on the server side. For current state of affairs, it will not > > > change anything, but when we later support server-side keep-alive and > > > later > > > connection pools, it will make it easier to retry the request over another > > > connection. > > > > Sure, perhaps that could be another on-markedown action? > > Not necessarily : currently, if you only close on the server side, the > effect will be propagated to the client side, so it already does the right > thing and at the same time will allow us to improve on this later.
Ok, understood. I'll try your suggestion.
