On Tue, Jan 15, 2019 at 09:51:12PM +0100, Tim Düsterhus wrote: > Willy, > > Am 15.01.19 um 21:41 schrieb Willy Tarreau: > >> Ideally the peers would exchange their local values, only. > > > > Yes and that's how this currently works. > > I believe they exchange what they believe to be the current global > connection count, instead of their local connection count, no?
No, there's no notion of global anything. The principle of the peers has always been to perform content replication between master and backup (or old to new process), so it's entirely push-based. The principle is that the last event is always right. Keep in mind that its first purpose was to make stickiness tables converge :-) > >> These are > >> obviously correct (otherwise it would be broken even without peers). > >> Then the instances aggregate the values (e.g. sum up all the values for > >> the number of connections) themselves to get the correct value. > > > > That's exactly how HapTech's stick-table aggregator works :-) > > Ha! So, I'm not inventing something new here. Unfortunately no :-) But the principle is exactly the same : you push stuff upwards, it aggregates with the other nodes and pushes backwards, and may optionally also push upwards for higher level aggregations. That's why push it interesting. Also, I've learned that some people use peers just to monitor activity : someone (I don't remember whom) has implemented a peers logger, and sees for example a key and an increment on gpc0 indicating that the source IP address corresponding to the key was detected or blacklisted. > >>> OK I'm merging Tim's patch now. > >>> > >> > >> It was not meant for actually applying (that's why it was missing out on > >> backport information as well), > > > > Bah, too late, misunderstood, sorry :-) > > I was just being unclear. My fault. I'll add a fat "PROOF OF CONCEPT" > warning the next time. You can just put "RFC" instead of "PATCH" ahead of the subject line, it's quite common especially in the Linux community and I will never merge such a patch without double-checking. > >> because fixing just one counter is fixing > >> the symptoms. I suspect the other stick table values are affected from a > >> possible underflow as well. > > > > I've checked the rest of the related code for variations and only this > > key works like a gauge, up and down. The other ones in the worst case will > > simply lose some counts but will not face such a problem. > > Okay. I guess my patch is the best short term solution then. Yes I think so and that's why I was OK with merging it. Cheers, Willy
