Broken pipe and Stream not writable errors about node-redis

[Swizec]

I also get these Stream not writable errors

events:12
        throw arguments[1];
                   ^
Error: Stream is not writable
    at Stream._writeOut (net:695:11)
    at Stream.write (net:681:17)
    at RedisClient.send_command     (/usr/local/lib/node/.npm/redis/0.3.5/package/index.js:645:16)
    at RedisClient.<anonymous>     (/usr/local/lib/node/.npm/redis/0.3.5/package/index.js:718:27)
    at Object.log (/home/skejti/Plateboiler-js/rapid.queue/logging.js:8:11)
    at Object.info (/home/skejti/Plateboiler-js/rapid.queue/logging.js:13:45)
    at Object.callback (/home/skejti/Plateboiler-js/rapid.queue/worker.js:19:11)
    at RedisClient.return_reply     (/usr/local/lib/node/.npm/redis/0.3.5/package/index.js:532:25)
    at RedisReplyParser.<anonymous> (/usr/local/lib/node/.npm/redis/0.3.5/package/index.js:382:18)
    at RedisReplyParser.emit (events:27:15)

[mranney]

What version of node and what operating system are you using?

It looks like the connection to the server went away, but somehow we didn't notice it.

[Swizec]

node: 0.3.0-pre
redis: 2.0.1

Runing on a debian.

Could this also be connected to sporadic ECONNRESET errors? Is there anything I can do to alleviate the problem?

[mranney]

Some questions: Is your Redis server on the same machine as your client? How many connections do you typically have open? Do you know if Redis is ever crashing and restarting?

It sounds like node_redis needs to handle this condition more gracefully, but the real issue is that your connections are getting reset at all.

[Swizec]

It's on the same machine. I have yet to notice redis crash, I'm not restarting it manually and running ps aux | grep redis tells me the redis-server process has been alive since Nov 02 (7 days).

There are around 30 clients connected at a time. When the process crashes the old clients disconnect right? Because the number is a bit high by my calculations.

For me personally the best solution would be if node_redis just quietly reconnected :)

Oh and I'm using the default redis configuration, I didn't touch a thing.

[mranney]

node_redis should absolutely not crash, and it should reconnect if the connection goes away. I'll dig into that a little more.

If your connections are getting reset while going across the same machine, this is a potentially more serious problem. Yes, if node exits, then all of the TCP connections it opened are closed by the kernel. Redis server should be detecting this.

[Swizec]

By the way, is there a way I can wait until the redis command queue is empty before I go into the next iteration of executing tasks? I'm not sure if that can be related to the problem, but I certainly wouldn't like results dying upon crashes because they're in the queue.

[mranney]

I just pushed a fix to the repo that should catch the most common of those write errors. Can you try it out and let me know if that fixes it? It's not in npm yet, but I can push it if installing from git is painful.

[mranney]

I just pushed 0.3.7 that has added "idle" and "drain" events. I believe "idle" does what you are looking for.

[Swizec]

I did a git clone and then performed "npm install ."

Still got this error:

events:12
throw arguments[1];
^
Error: Stream is not writable
at Stream._writeOut (net:695:11)
at Stream.write (net:681:17)
at RedisClient.send_command (/usr/local/lib/node/.npm/redis/0.3.6/package/index.js:652:16)
at RedisClient. (/usr/local/lib/node/.npm/redis/0.3.6/package/index.js:723:27)
at Object.log (/home/skejti/Plateboiler-js/rapid.queue/logging.js:8:11)
at Object.info (/home/skejti/Plateboiler-js/rapid.queue/logging.js:13:45)
at Object.callback (/home/skejti/Plateboiler-js/rapid.queue/worker.js:19:11)
at RedisClient.return_reply (/usr/local/lib/node/.npm/redis/0.3.6/package/index.js:534:25)
at RedisReplyParser. (/usr/local/lib/node/.npm/redis/0.3.6/package/index.js:381:18)
at RedisReplyParser.emit (events:27:15)

Should I install somehow differently?

[mranney]

You are still running the older version for whatever reason.

Please do an "npm update" and you should get v0.3.7, which has two fixes I just did today.

[Swizec]

Yep, with your second comment (where you said you pushed 0.3.7) it seems the issue is gone for now. Maybe npm needed the version to change?

Thanks for the quick fix :)

[mranney]

Glad to hear it.