From: antirez <antirez@gmail.com>
Date: Fri, 22 May 2009 16:35:51 +0000 (+0200)
Subject: critical bug about glueoutputbuffers=yes fixed. Under load and with pipelining and... 
X-Git-Url: https://git.saurik.com/redis.git/commitdiff_plain/6fdc78ac69865b79b16fda97cf29a063dc3d026a

critical bug about glueoutputbuffers=yes fixed. Under load and with pipelining and clients disconnecting on the middle of the chat with the server, Redis could block. Now it's ok
---

diff --git a/TODO b/TODO
index 02a5f577..f09830e2 100644
--- a/TODO
+++ b/TODO
@@ -5,7 +5,6 @@ BEFORE REDIS 1.0.0-rc1
  * maxmemory support
  * maxclients support
  * Resize the expires and Sets hash tables if needed as well? For Sets the right moment to check for this is probably in SREM
- * TTL command that returns -1 if a key is not volatile otherwise the time to live of a volatile key in seconds.
  * What happens if the saving child gets killed or segfaults instead of ending normally? Handle this.
  * Make sinterstore / unionstore / sdiffstore returning the cardinality of the resulting set.
  * check 'server.dirty' everywere
diff --git a/redis.c b/redis.c
index 1e620a6c..ea7d4b27 100644
--- a/redis.c
+++ b/redis.c
@@ -1119,7 +1119,8 @@ static void glueReplyBuffersIfNeeded(redisClient *c) {
             listDelNode(c->reply,ln);
         }
         /* Now the output buffer is empty, add the new single element */
-        addReplySds(c,sdsnewlen(buf,totlen));
+        o = createObject(REDIS_STRING,sdsnewlen(buf,totlen));
+        if (!listAddNodeTail(c->reply,o)) oom("listAddNodeTail");
     }
 }