madsimian / em-redis Goto Github PK

Hi,

I noticed that the array obtained in the test:

user_interests.should == [["second-interest", "first-interest"], ['third-interest']]

around line 755 in redis_commands_spec.rb is random (the two terms in the first subarray might be exchanged). Therefore, this test randomly fails. Currently, this test is deactivated in the Debian package.

Cheers,

Cédric

When the client disconnects (potentially due to timeout?) the previous command is not restarted nor is there any notification (callback). If the consumer was waiting on a command -- say a blocking one like BRPOP -- then the consumer will end up hanging indefinitely as em-redis will not reinvoke the command after the reconnect. However, given that not all commands are idempotent, a better way would be to invoke a 'reconnect' callback after em-redis reconnects.

Current subscribe semantics do not work. Any plans to support them?

http://redis.io/commands/setex
Probably more effective than the 2 command version that set() can do at the moment

Hey,

Here is a patch to allow for reconnection : http://gist.github.com/524175

I'm not really sure how to test it except by hand (which I did), by turning the server on and off.
Also, the connected? method is useful to avoid stacking up commands. Clients can then decide not to send additional data if the server is not connected.

Let me know if you can integrate it!

According to Redis documentation, setnx takes only two parameters (key and value).
Within redis_protocol.rb, setnx is listed as a bulk command. This seems to cause the send_command() function to append the length of the last argument passed into the function to the command sequence, which causes a Redis error.

Example:
The Ohm library calls

 key[:_lock].setnx(Time.now.to_f + 0.5)

The send_command() function receives a 3-element array:

 argv = [ "setnx", "OhmClassName:132:_lock", "1314673377.348075"]

Because setnx is listed in BULK_COMMAND array at header of redis_protocol.rb, send_command() takes the length of "1314673377.348075" and inserts it into the command list as if it were the value for the command, like so:

 setnx OhmClassName:132:_lock 17 1314673377.348075

This results in an error

:1 -ERR unknown command '1314673377.348075' 

because redis interprets the inserted length (17) as the value, and treats the timestamp that follows as if it were a command.

Changing BULK_COMMAND to make setnx to false seems to rectify this behavior, but this is happening with other Redis commands listed in there that only take two parameters (e.g. 'set', 'sismember', etc). Even for those that take multiple arguments (e.g. sadd) it seems unusual to add the length of the remainder into the command, rather than just appending the remaining arguments.

What is the logic behind the BULK_COMMAND array and the thought behind what commands are listed there, and that block in send_command()? Is there something I am missing?

(Thanks greatly for having made this in the first place, btw!)

Hey,

It seems that the lib doesn't support ZREMRANGEBYSCORE : http://code.google.com/p/redis/wiki/ZremrangebyscoreCommand

Is that on purpose?