07:09:41 GMT <Abhijit> hi
07:10:23 GMT <Abhijit> i have a data stream {a:1, .........} again {a:1,.....} can i use redis hash to store this? it has duplicate object
07:11:46 GMT <ephemera_> Can I find executed command history?
07:12:49 GMT <minus> ephemera_: with the monitor command you can see what commands are being executed, and if you set a high enough log level commands might appear in the logs, otherwise no
07:14:18 GMT <ephemera_> minus: thanks
07:54:08 GMT <billtsui> Hi,After binding my IP(10.10.21.229),I can't using /etc/init.d/redis stop, It try to connect 127.0.0.1:6379,How can I fix it?
07:56:11 GMT <billtsui>  Hi,After binding my IP(10.10.21.229),I can't using /etc/init.d/redis stop, It try to connect 127.0.0.1:6379,How can I fix it?
08:53:42 GMT <badboy_> Change the init script.
09:17:27 GMT <Dev0n> Hey, if you have multiple deployments each either own database, would a distributed redis setup be a good use case for providing a centralised login system? So when a user logs in from the main entry point, a look up using redis will send these users to their specific deployment.
09:30:33 GMT <minus> gut feeling: probably not
09:31:48 GMT <minus> Dev0n: sounds more like a case for oauth or the like (central login system + the actual system is granted access to the account)
09:33:06 GMT <Dev0n> minus, I'm trying to figure out the best way to check the multiple deployments to figure where a user belongs
09:33:39 GMT <Dev0n> I know one solution would be to have a central database with all the users from all deployments and info on where they should be redirected
09:34:08 GMT <minus> that's what seems the simplest (thus best) solution
09:34:30 GMT <Dev0n> figured I could use redis to keep the user data within their respective deployments and use its distributed features to look across rather than having a central place
09:35:06 GMT <minus> that doesn't quite work; redis does not have master-master replication
09:35:18 GMT <minus> etcd might work for that, though i've never used it
09:35:21 GMT <Dev0n> is it not able to search across connected client?
09:35:25 GMT <Dev0n> err instances*
09:35:47 GMT <minus> well, you'd have to connect to all instances and search in each one
09:36:46 GMT <Dev0n> hum, guess I'm going to have to look for something that allows distributed searching, instead of me having to connect to n clients to run n queries and handling that on app logic
09:37:05 GMT <minus> do yourself a favor and use a central database
09:37:47 GMT <minus> or give users the direct address of the respective deployment
09:40:18 GMT <Dev0n> gotcha, thanks minus, seems like the simplest solution at this point
15:52:36 GMT <ahfeel> Hi :)
15:53:46 GMT <ahfeel> If I care about extra round trip latency between my frontends and my redis servers, is it a good practice to "batch" exists / hincrby / expire (on the whole hash) into an eval of lua script ?
15:55:52 GMT <minus> sounds unnecessary unless your latency between the servers is huge
15:56:19 GMT <ahfeel> well, I've measured latency of every redis command roundtrip being around 1ms
15:57:04 GMT <ahfeel> I won 20/30ms on request processing time by grouping gets and whatever stuff I could to avoid all those roundtrips
15:57:15 GMT <minus> for commands you don't need the result immediately you can use pipelining, depending on whether you client supports it
15:57:47 GMT <ahfeel> yeah, I do, but for the exact pattern i'm describing I'm a bit confused
15:57:54 GMT <ahfeel> I want to hincrby a key
15:58:03 GMT <ahfeel> but I don't know if the hash already exists or not
15:58:13 GMT <ahfeel> and I want it to expire
15:58:38 GMT <ahfeel> so, doing exists() => hincrby => expire if not exists is 3ms
15:58:47 GMT <ahfeel> (and in any case 2ms minimum)
15:59:18 GMT <ahfeel> while I could maybe just do an eval an make it 1ms, but I'm not sure it's a good pattern
15:59:41 GMT <minus> do you need to know if the key exists in client code before the hincrby? otherwise just run hincrby and check its return value and you're down to 1 roundtrip
16:00:08 GMT <ahfeel> well hincrby may return 1 for new keys in the hash
16:00:12 GMT <minus> it's not very bad, but you do add code in a different language
16:00:22 GMT <ahfeel> but it doesn't mean the hash doesn't already exists with other keys
16:01:39 GMT <minus> aye. if your data structure doesn't guarantee that that key is set always then that won't work