Node-redis: Difference between unref(), quit() and end()

[Mickael-van-der-Beek]

Like the title indicates, even after reading the documentation, it's unclear to me what the difference is between unref(), quit() and end().

• Which one should I use and in which use case ?

end() seems to close a connection without waiting for all the sockets to be closed.
unref() seems to wait for all the commands to end.
quit() seems to be similar to unref().

• Since unref() doesn't have a timeout, is it guaranteed to end or should I set a timeout ?
• Is the end event called unconditionally from which one I called ?

[brycebaril]

end() is designed for use where you're terminating the application NOW, e.g. an uncaughtException handler, and don't anticipate or want to wait for (if any) replies from commands you may have sent that have not come back from Redis yet.

quit() is designed for when you are done with this connection and want to close it, but allow the unfinished activity to complete. In most cases if you are trying to end the connection, use quit()

unref() is not designed to compete with these to options, but simply to allow your application to exit if the only asynchronous thing remaining is the Redis client. This is commonly the case for some sort of script where you are doing a batch query, or a test that connects to Redis. It behaves identically to the unref here http://nodejs.org/api/net.html#net_server_unref

[brycebaril]

Then end event only gets emit from when you call quit() apparently. Not sure exactly why without research.

[techsin]

if you don't call quit ever what happens.

[brycebaril]

@techsin If you never close the redis connection, your node application will sit and wait forever connected to the Redis server.

[techsin]

what if application has closed down, but redis server is still up. would that make redis server hold reference? would that be kind of a memory leak

sorry i wasn't clear first time

[brycebaril]

Nope, if the application closes it will terminate the client connection and the Redis server will terminate the reference on its side, so no memory leak.