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. Cheers, Willy
