06:00:42 GMT <sparrow_> hi
06:04:54 GMT <sparrow_> as i am new to redis, i get an idea to store a hash in hash to create a separate key and make an entry in registry of the key,
06:06:29 GMT <sparrow_> but there is problem as i am using jedis as redis client, doing in this way make two command execution. first to create a key , second to store key in registry set.
06:07:19 GMT <sparrow_> but the problem is what if the one command get failed, how to rollback the previous executed command?
06:09:43 GMT <sparrow_> as i am new to redis, i get an idea to store a hash in hash to create a separate key and make an entry in registry of the key, but there is problem as i am using jedis as redis client, doing in this way make two command execution. first to create a key , second to store key in registry set. but the problem is what if the one command get failed, how to rollback the previous executed command?
06:19:08 GMT <slact> sparrow: you can use MULTI/EXEC, or put your commands into a Lua script
06:20:32 GMT <slact> sparrow_: those are two different constructs to execute several commands atomically. If all you want is roll-back if a command returns an error, MULTI/EXEC should be enough.
06:26:13 GMT <sparrow_> slact: thanks for giving response, but i want to know that i have given 3 commands using multi/exec like this {cmd 1; cmd 2; cmd 3;}, now cmd 1 and cmd 2 exceuted successfully but i got the failure in cmd 3 execution, so i want either executes all cmd or none. please help
06:30:02 GMT <slact> sparrow_: http://redis.io/topics/transactions ; there is no rollback mechanism in Redis, so if you want to atomically make sure all commands will succeed, put them into a Lua script: http://redis.io/commands/eval
06:32:59 GMT <sparrow_> slact: sorry to ask but please tell me by lua script it is sure that either all cmd will execute or none?
06:34:19 GMT <slact> sparrow_: you can write a script that will do this, but you will need to write the logic to make sure your commands won't fail.
06:36:00 GMT <sparrow_> slact: how can we sure that command will not fail? it is not in our hand?
06:37:53 GMT <slact> sparrow_: a command usually only fails if you're applying it to the wrong type of key, like an INCRBY foo 1 where foo is a hash will produce an error. so check that your keys are what you expect them to be, and you won't have errors. Of course, check the documentation for each command to see its error conditions.
06:39:16 GMT <sparrow_> slact: thanks a lot man for giving your time.
06:39:26 GMT <slact> you're welcome.
06:46:15 GMT <sparrow_> please tell me, what is the size of waiting queue in redis? ( how many request it can hold at a time ?)
06:46:46 GMT <slact> As many as can fit into memory.
06:49:32 GMT <sparrow_> is this "#maxclients 10000" define the waiting queue?
06:49:52 GMT <slact> no
12:20:02 GMT <gabriel_> hello, just a quick question. when using redis rdb persistence, redis each consecutive write writes just the diff between in memory dataset and stored dataset, right? so it does not rewrite the whole file
12:23:45 GMT <antirez> gabriel_: wrong, with RDB Redis writes the *whole* dump from time to time. With AOF instead is incremental.
12:31:00 GMT <seveg> antirez: so i guess it's not wise to dump 35GB every minute
12:39:25 GMT <michel_v> seveg: well the IO problem is obvious
12:39:27 GMT <antirez> seveg: Depends on the dataset and your hardware, but I guess it's better to use AOF with such numbers (data set size and frequency)
12:39:52 GMT <antirez> seveg: a compromise is to use AOF, but use it without any fsync policy just letting the kernel flush the data on disk when it wishes so
12:39:59 GMT <antirez> (every 30 sec by default)
12:40:13 GMT <antirez> So it's a similar durability to RDB but will be easier on the server load.
12:42:41 GMT <seveg> antirez: i'm affraid about restart performance with AOF
12:46:27 GMT <seveg> antirez: but thanks for your answer
12:46:29 GMT <antirez> seveg: yep that could be a concern. We have plans to have RDB as AOF preamble, so that it will be much faster, but so far working at other stuff
12:46:47 GMT <antirez> you are welcome
14:11:47 GMT <nnog> hey, I've been reading the modules API and getting excited. However... there is already a module that patches existing command in a "hacky" way. Are there plans for a proper API to patch existing command funcs?
14:12:35 GMT <nnog> maybe by swapping the command function out, return the original command function pointer so that one could write the replacement command in terms of the original?
14:13:24 GMT <nnog> might be worth adding, just because I imagine people will otherwise be patching and renaming commands anyway
14:14:34 GMT <nnog> e.g. modules like this that rely on server.h and recompilation: https://github.com/RedisLabsModules/pam_auth/blob/master/pam_auth.c
14:16:09 GMT <nnog> personally I'm interested in patching existing commands because I want an expanded version of Redis's keyspace notification options
19:38:11 GMT <mustmodify> I'm about to put Redis into production. What are the common failure scenarios? What's the typical backup strategy?
20:33:47 GMT <solenodic> hey, does redis's pub sub have ordering guarantee?
20:40:37 GMT <minus> should be guaranteed, judging by how redis works. it's not reliable though
20:42:07 GMT <minus> read the manual though