Plans for EVAL support? about twemproxy HOT 8 CLOSED

We do have plans to support EVAL.

But before we support EVAL/EVALSHA, we need to support #9. This is because, if sharding is done on the "keynames", we would require all the "keys" in EVAL command to map to the same server. Unlike mget and del, we cannot fragment EVAL command.

what do you think?

from twemproxy.

It makes a lot of sense.

Thanks

Javi

from twemproxy.

we have 'hash tags' now on head. so this should be easy to support

from twemproxy.

+1 For this feature

from twemproxy.

Hi manjuraj,

I have written a patch that provides rudimentary EVAL/EVALSHA support for scripts that take exactly one key. I can expand that to more generic support, but I wanted to know if you had any thoughts about how that should look like.

Specifically:

1. The sharding algorithm (or even the characters that determine the hash tag part of a key) isn't known in the redis protocol parser (nc_redis.c). We either have to expose this to the parser, or we have to expand struct msg to hold multiple keys so that either the parser or server_pool_conn() can determine if the query is well-formed. Do you have an opinion either way?
2. Do we support EVAL of scripts that take 0 keys (e.g. EVAL "return 0" 0) - should we execute this on an arbitrary server, or make it mandatory for at least 1 key to be provided even if the script doesn't use the key so the server the script is executed on is deterministically picked?

Thanks

from twemproxy.

@ferenyx send a pull request :)

I think for EVAL and EVALSHA commands taking >= 1 key, we should do sharding on the 1st key with the hope that client uses 'hash tags' and has the same hash tag for all the keys in the EVAL and EVALSHA command.

See #54 (comment) for more discussion on this

from twemproxy.

I sent a pull request, and that's now at issue #60. Thanks!

from twemproxy.

Fixed by @ferenyx. See: 4e117f8

from twemproxy.