diff options
author | David Benjamin <davidben@mit.edu> | 2013-07-14 14:56:10 -0400 |
---|---|---|
committer | Karl Ramm <kcr@1ts.org> | 2013-08-08 00:24:58 -0400 |
commit | 32da3192e9169118365a236ac8ccd1bf982df020 (patch) | |
tree | e6872abc2ca92f61f00cf080c1bdf2e8122983ed | |
parent | b9ec2cdc23b77fd86b69ba884c5513f3f71cf025 (diff) |
Defensively avoid waiting on non-initial SERVACKs
Although the previous commit should make it very unlikely we screw up the
subscription sharding, be defensive about waiting for SERVACKs. ZSubscribeTo
does mess up, Z_SendFragmentedNotice will shard with a z_multiuid. In that
case, although the second packet will get a SERVACK, Z_ReadWait kindly drops it
on the floor. The ZIfNotice will then just hang.
Tested by bumping zwgc's BATCH_SIZE up to 200, reverting the previous commit,
and strace.
-rw-r--r-- | lib/ZSubs.c | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/lib/ZSubs.c b/lib/ZSubs.c index e0d39ee..7c7949b 100644 --- a/lib/ZSubs.c +++ b/lib/ZSubs.c @@ -188,6 +188,11 @@ Z_SendAndWaitForServer(ZNotice_t *notice, retval = ZSendPacket(buf, len, waitforack); if (retval != ZERR_NONE) return (retval); + /* Z_ReadWait drops non-initial SERVACKs and SERVNAKs on the floor. We + should never see a non-initial one here, but be defensive about bugs in the + sharding code above. */ + if (!ZCompareUID(¬ice->z_multiuid, ¬ice->z_uid)) + return (retval); if ((retval = ZIfNotice(&retnotice, (struct sockaddr_in *)0, ZCompareUIDPred, (char *)¬ice->z_uid)) != ZERR_NONE) |