Add some more notes and tests

Author: Ruben Bridgewater

changelog.md

@@ -1,9 +1,9 @@
 Changelog
 =========
 
-## v.2.2.0 - xx Oct, 2015 - The peregrino falcon
+## v.2.2.0 - 12 Oct, 2015 - The peregrino falcon
 
-The peregrino falcon is the fasted bird on earth and this is what this release is all about: We increased performance for heavy usage by up to **400%** [sic!] and increased overall performance for any command as well. Please check the benchmarks in the [README.md](README.md) for further details.
+The peregrino falcon is the fasted bird on earth and this is what this release is all about: Increased performance for heavy usage by up to **400%** [sic!] and increased overall performance for any command as well. Please check the benchmarks in the [README.md](README.md) for further details.
 
 Features
 
@@ -18,15 +18,17 @@ Features
 
 Bugfixes
 
--  Fix a javascript parser regression introduced in 2.0 that could result in timeouts on high load. ([@BridgeAR](https://github.com/BridgeAR))
+-  Fix a javascript parser regression introduced in 2.0 that could result in timeouts on high load. <b>*</b> ([@BridgeAR](https://github.com/BridgeAR))
 -  Fixed should_buffer boolean for .exec, .select and .auth commands not being returned and fix a couple special conditions ([@BridgeAR](https://github.com/BridgeAR))
 
+* I was not able to write a regression test for this, since the error seems to only occur under heavy load with special conditions. So please have a look for timeouts with the js parser, if you use it and report all issues and switch to the hiredis parser in the meanwhile. If you're able to come up with a reproducable test case, this would be even better :)
+
 If you do not rely on transactions but want to reduce the RTT you can use .batch from now on. It'll behave just the same as .multi but it does not have any transaction and therefor won't roll back any failed commands.<br>
 Both .multi and .batch are from now on going to cache the commands and release them while calling .exec.
 
 Please consider using .batch instead of looping through a lot of commands one by one. This will significantly improve your performance.
 
-Here are some stats compared to ioredis 1.9.1:
+Here are some stats compared to ioredis 1.9.1 (Lenovo T450s i7-5600U):
 
                       simple set
           82,496 op/s » ioredis
@@ -38,7 +40,7 @@ Here are some stats compared to ioredis 1.9.1:
 
                       simple get with pipeline
           10,233 op/s » ioredis
-          26,541 op/s » node_redis
+          26,541 op/s » node_redis (using .batch)
 
                       lrange 100
            7,321 op/s » ioredis
@@ -54,6 +56,10 @@ Here are some stats compared to ioredis 1.9.1:
 
 To conclude: we can proudly say that node_redis is very likely outperforming any other node redis client.
 
+Known issues
+
+-  The pub sub system has some flaws and those will be addressed in the next minor release
+
 ## v2.1.0 - Oct 02, 2015
 
 Features:

test/batch.spec.js

@@ -63,6 +63,21 @@ describe("The 'batch' method", function () {
                     client.end();
                 });
 
+                it("returns an empty array", function (done) {
+                    var batch = client.batch();
+                    batch.exec(function (err, res) {
+                        assert.strictEqual(err, null);
+                        assert.strictEqual(res.length, 0);
+                        done();
+                    });
+                });
+
+                it("returns an empty array if promisified", function () {
+                    return client.batch().execAsync().then(function(res) {
+                        assert.strictEqual(res.length, 0);
+                    });
+                });
+
                 it("returns an empty result array", function (done) {
                     var batch = client.batch();
                     var async = true;

test/pubsub.spec.js

@@ -285,6 +285,51 @@ describe("publish/subscribe", function () {
                 });
             });
 
+            // TODO: Fix pub sub
+            // And there's more than just those two issues
+            describe.skip('FIXME: broken pub sub', function () {
+
+                it("should not publish a message without any publish command", function (done) {
+                    pub.set('foo', 'message');
+                    pub.set('bar', 'hello');
+                    pub.mget('foo', 'bar');
+                    pub.subscribe('channel');
+                    pub.on('message', function (msg) {
+                        done(new Error('This message should not have been published: ' + msg));
+                    });
+                    setTimeout(done, 500);
+                });
+
+                it("should not publish a message multiple times per command", function (done) {
+                    var published = {};
+
+                    function subscribe(message) {
+                        sub.on('subscribe', function () {
+                            pub.publish('/foo', message);
+                        });
+                        sub.on('message', function (channel, message) {
+                            if (published[message]) {
+                                done(new Error('Message published more than once.'));
+                            }
+                            published[message] = true;
+                        });
+                        sub.on('unsubscribe', function (channel, count) {
+                            assert.strictEqual(count, 0);
+                        });
+                        sub.subscribe('/foo');
+                    }
+
+                    subscribe('hello');
+
+                    setTimeout(function () {
+                        sub.unsubscribe();
+                        setTimeout(function () {
+                            subscribe('world');
+                        }, 400);
+                    }, 400);
+                });
+            });
+
             afterEach(function () {
                 sub.end();
                 pub.end();