From 32da3192e9169118365a236ac8ccd1bf982df020 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Sun, 14 Jul 2013 14:56:10 -0400 Subject: 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. --- lib/ZSubs.c | 5 +++++ 1 file changed, 5 insertions(+) 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) -- cgit v1.2.3