On 09/21/2015 10:01 PM, Pradeep Jindal wrote: > Good to know that you were able to reproduce the same, I will wait for your > response while I try to debug it myself as well. Thanks > > On Sep 22, 2015 1:26 AM, "Willy Tarreau" <[email protected] <mailto:[email protected]>> > wrote: > > Pradeep, I reproduce it now, thank you very much for your detailed > configuration and procedure. I have no idea why it doesn't work > reliably with this test while it does work with a regular IP address, > it could be an on-wire protocol issue, I'll wait for Emeric tomorrow > in the morning and we'll check this together. > > All I can say for now is that it *seems* that the first update is always > OK in both directions and that after this one only connections sent to > the first one who sent the first update continue to work. Maybe there's > a state machine bug somewhere, maybe even related to the length of the > key or whatever. We'll keep you informed! > > Thanks! > Willy >
Hi Pradeep, Your config file was useful. We've been able to reproduce several malfunctions. You will find the fixes in attachment. Willy have just merge them in the git master. Could you test with those patches and tell us if they fix your issues. R, Emeric
>From 36077d300c782ed51b55377bc029c19b2a1ef379 Mon Sep 17 00:00:00 2001 From: Emeric Brun <[email protected]> Date: Tue, 22 Sep 2015 15:05:06 +0200 Subject: [PATCH 1/3] BUG/MEDIUM: peers: some table updates are randomly not pushed. If an entry is still not present in the update tree, we could miss to schedule for a push depending of an un-initialized value (upd.key remains un-initialized for new sessions or isn't re-initalized for reused ones). In the same way, if an entry is present in the tree, but its update's tick is far in the past (> 2^31). We could consider it's still scheduled even if it is not the case. The fix consist to force the re-scheduling of an update if it was not present in the updates tree or if the update is not in the scheduling window of every peers. --- src/stick_table.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/stick_table.c b/src/stick_table.c index a51bde3..c3b76ad 100644 --- a/src/stick_table.c +++ b/src/stick_table.c @@ -255,9 +255,11 @@ struct stksess *stktable_touch(struct stktable *t, struct stksess *ts, int local /* If sync is enabled and update is local */ if (t->sync_task && local) { - /* If this entry was already pushed to a peer - We want to push it again */ - if ((int)(ts->upd.key - t->commitupdate) <= 0) { + /* If this entry is not in the tree + or not scheduled for at least one peer */ + if (!ts->upd.node.leaf_p + || (int)(t->commitupdate - ts->upd.key) >= 0 + || (int)(ts->upd.key - t->localupdate) >= 0) { ts->upd.key = ++t->update; t->localupdate = t->update; eb32_delete(&ts->upd); -- 1.9.1
>From 345a7ad62a6879a5e007181c360bf5cc4f4b7887 Mon Sep 17 00:00:00 2001 From: Emeric Brun <[email protected]> Date: Tue, 22 Sep 2015 15:34:19 +0200 Subject: [PATCH 2/3] BUG/MEDIUM: peers: same table updates re-pushed after a re-connect Some updates are pushed using an incremental update message after a re-connection whereas the origin is forgotten by the peer. These updates are never correctly acknowledged. So they are regularly re-pushed after an idle timeout and a re-connect. The fix consists to use an absolute update message in some cases. --- src/peers.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/peers.c b/src/peers.c index f628a7f..b6b48ed 100644 --- a/src/peers.c +++ b/src/peers.c @@ -250,8 +250,8 @@ static int peer_prepare_updatemsg(struct stksess *ts, struct shared_table *st, c /* construct message */ /* check if we need to send the update identifer */ - if (st->last_pushed && ts->upd.key > st->last_pushed && (ts->upd.key - st->last_pushed) == 1) { - use_identifier = 0; + if (!st->last_pushed || ts->upd.key < st->last_pushed || ((ts->upd.key - st->last_pushed) != 1)) { + use_identifier = 1; } /* encode update identifier if needed */ -- 1.9.1
