00:00:02 GMT <drfraker> on redis-cli monitor it appears that everything is working ok.
00:00:27 GMT <drfraker> anyone here?
00:07:58 GMT <xep> drfraker: Predis? That's the PHP Redis library?
00:14:12 GMT <drfraker> yeah Predis
00:14:45 GMT <drfraker> 1282:signal-handler (1463444004) Received SIGTERM scheduling shutdown... 1282:M 16 May 18:13:24.646 # User requested shutdown... 1282:M 16 May 18:13:24.647 * Saving the final RDB snapshot before exiting. 1282:M 16 May 18:13:24.647 # Failed opening .rdb for saving: Permission denied 1282:M 16 May 18:13:24.647 # Error trying to save the DB, can't exit. 1282:M 16 May 18:13:24.647 # SIGTERM received but errors trying to shut down the ser
00:14:51 GMT <drfraker> This is from my redis server log.
00:15:09 GMT <drfraker> I just changed the overcommit_memory to 1. I read that would help
00:38:42 GMT <xep> argh he left
00:39:30 GMT <xep> it's like people expect IRC to be a very "synchronous" form of communication when in fact a lot of the time it's more asynchronous
00:40:45 GMT <xep> but a case like his kind of looks like he messed up something stupid somewhere
07:07:22 GMT <minus> xep: what annoys me more is that noone ever reads the error messages. It does say why it fails (permission denied), even if it might not be the only problem.
07:11:44 GMT <bugzbunny> minus: While that sounds reasonable
07:11:53 GMT <bugzbunny> minus: It's hard to tell why
07:12:13 GMT <bugzbunny> Usually the errors are like [Error 256] Permission Denied
07:12:19 GMT <bugzbunny> Okay :/
07:19:53 GMT <antirez> xep: cool to have Twemproxy with Sentinel support, maybe we could like it to the Sentinel doc?
07:36:32 GMT <antirez> dvirsky_: is the full text search module supposed to be released today?
07:40:26 GMT <xep> minus: right? I wanted to ask him about that
07:40:32 GMT <xep> antirez: that would be cool!
07:41:53 GMT <antirez> xep: the problem with Twemproxy is that it's a non trivial project so in theory it needs a maintainer with many hours to spend per week working on it. We have the same problem with different parts of the Redis ecosystem.
07:42:34 GMT <xep> yeah.. and Twitter has pretty much abandoned it. That's why I forked it and merged andyqzb's patch
07:43:04 GMT <xep> once Redis Cluster is mature enough for production we shouldn't even need it anyway
07:44:06 GMT <antirez> xep: Redis Cluster is IMHO already much more mature than using twemproxy, the problem is that the clients ecosystem is not yet very well developed, so tweproxy, with a new "cluster" target, could be an excellent way to transition...
07:44:23 GMT <antirez> Moreover there are workloads of pure get/set caching, where the proxy could be a simpler and good solution
07:44:38 GMT <antirez> however even for the caching scenario, the idea is to add a special support for that in Redis Cluster
07:44:59 GMT <antirez> that is, when a special mode where, when a master fails, instead of triggering a failover the cluster just reassigns the missing slots to other alive instances.
07:45:26 GMT <xep> but for now it's a headache if you have, say, PHP writing to this "cluster" through twemproxy and it doesn't support Sentinel fail. I guess you could hack it with haproxy but I notice its healthcheck adds a bunch of traffic
07:46:05 GMT <xep> and you want to like upgrade Redis -- so fail to the slaves except twitter/twemproxy won't do it unless you do the haproxy hack
07:46:14 GMT <antirez> yes it's totally a great feature to have... wonder why it's not getting merged. Maybe just just that tha maintainer has no time to review, not that it would not be merged otherwise.
07:46:38 GMT <xep> Yah, I think idning just doesn't have time. He hasn't responded in nearly a year now
07:46:57 GMT <xep> And you're right, it is probably more mature than twemproxy at this point
07:47:43 GMT <xep> I was actually planning on giving it a try on whatever next tier I get to build out
07:48:16 GMT <antirez> xep: at Redis Conf there were a number of users running Redis Cluster in production. There are a few things to smooth, like faster reshardings and better support for very large clusters, but mostly in areas where Twemproxy can't help as well AFAIK.
07:48:52 GMT <antirez> btw the right approach is what you say: test it for your intended use case and see if it's a match or not :-)
07:49:19 GMT <xep> Hm, interesting. I was at RedisConf BTW :) I may have missed some talks / didn't get a chance to talk Redis Cluster with anyone
07:50:50 GMT <xep> that whole module bombshell that was dropped got me really excited -- I actually have a "ZSUMRANGE" implemented in Lua on prod, though we limit those sets to 1k elements. still I can't wait to get to use the low level API
07:54:42 GMT <xep> antirez: good point about lack of client support. twemproxy is a convenient thing to shim in between the client and server to get most of what you want
07:55:40 GMT <xep> the twemproxy code base isn't that huge, I'm going to have to think about a "cluster" target for it now. I need to read more about Redis Cluster and play with it
07:57:08 GMT <xep> I actually ended up writing a Python module (twemredis-py) that emulates twemproxy behavior (as far as sharding anyway) that I've used for all sorts of stuff from analyzing data to running ETL jobs
07:58:00 GMT <xep> it's a WIP, only supports the md5 algorithm currently because I'm currently the only user and that's hash function I use
08:01:52 GMT <xep> I imagine it's kind of a niche use case. Also I needed an excuse to brush up on my Python after all these years. In case anyone can get any use out of it https://github.com/mishan/twemredis-py/
08:05:51 GMT <dvirsky__> man, cluster support in modules would be amazing :)
08:10:29 GMT <antirez> For now true data types in modules is the first thing we'll get :-) But soon or later (future versions likely) cluster support would be great to play multi-node new protocols
08:16:42 GMT <xep> anyway, I better head to sleep. keep up the great work! since I've been working with Redis at work heavily the last few months, I've just been blown away by how fast and neat it is. We use it for persistent stores and caching. I keep pushing to put more stuff in Redis since it's so fast and that's a big win. There shall definitely be more Redis at if(we) in the future if I have anything to say about it :)
08:17:40 GMT <xep> we probably have around a terabyte between the three tiers right now
09:28:20 GMT <pBBBBB_BBBBB> thread safety on Set is on the onus of the dev, correct?
09:37:19 GMT <dvirsky__> antirez: this discussion is better to be handled here - do you think you'll add GEO support in the low level API? I want to add geo filtering for the search engine, and I'm wondering what's the best way to do it
10:31:41 GMT <antirez> dvirsky_: yes I want to look into exporting the GEO API to modules, I'm not sure at what level, but the most value is in providing low level access AFAIK. However it's hard to provide low level access to GEO without exposing internal details, so there is some work to do.
10:33:14 GMT <antirez> dvirsky__: i wanted to ask you a thing about modules API
10:33:24 GMT <antirez> dvirsky__: the subject is in-module data type RDB serialization
10:34:08 GMT <antirez> dvirsky__: basically I don't want to expose too much complexity to the module writer, as usually. I'm orienting towards the idea of *just* provide an API to read/write from/to the RDB just saying, here I want to serialize this value as N string values.
10:34:29 GMT <antirez> dvirsky__: I've the feeling that the "N string values" abstraction can work basically for everything. Do you see any problem with that?
10:34:48 GMT <dvirsky__> why not just give the writer/reader  interface?
10:35:35 GMT <dvirsky__> I was just on my way to get lunch, let's continue in 20, ok?
10:35:41 GMT <antirez> dvirsky__: because in that case the module must implement serialization per se, like, length prefixes, number of items. RDB is able to do all that with compressed encodings, so why to do it again?
10:36:12 GMT <antirez> dvirsky__: no prob I'm going as well, see you later, I'm not sure when I'll be chatting again but we'll be able to meet for sure :-)
10:37:13 GMT <dvirsky__> I see. let me think about it. I see why it will be simple. back later :) bon appetite
11:44:12 GMT <minus> the GEO* command docs seem to be outdated, they still show a "beta only" notice http://redis.io/commands/geoadd
11:58:12 GMT <vincent_> "redis-sentinel"-question: Can the dynamic config be written to separate file?
12:00:17 GMT <dvirsky__> antirez: made a little draft re how I see the API https://gist.github.com/dvirsky/1ae363ca8f46ed34ac91afd583bb7775
12:00:39 GMT <dvirsky__> basically you get a writer and write an object at a time, resulting from the perspective of redis in a list
12:00:45 GMT <dvirsky__> and the other way around for reading
12:02:05 GMT <dvirsky__> minus: maybe worth a PR :)
12:05:26 GMT <minus> maaaaaybe
12:05:29 GMT <minus> busy atm
12:09:35 GMT <vincent_> as in: Not into the configuration file itself?
13:36:35 GMT <dvirsky__> antirez: I think I found a pretty critical bug in the modules
13:37:42 GMT <dvirsky__> trying to fix and make a PR
13:41:45 GMT <dvirsky__> ok, basically passing a redis string as a field in HashSet causes redis to crash if you use that string later on
13:41:54 GMT <dvirsky__> fixed it
13:49:12 GMT <dvirsky__> antirez: https://github.com/antirez/redis/pull/3239
14:51:56 GMT <vincent_> Why would sentinel use a delimiter anyways: "# Generated by CONFIG REWRITE" and then write the id anywhere in the config?!
15:23:14 GMT <ahfeel> antirez: around ? :)
16:30:48 GMT <ahfeel> Anyone around running redis on a high traffic website ?
18:44:13 GMT <markuman> RedisModuleString *strings_in_c_are_a_peace_of_shit = RedisModule_CreateString (ctx, version, sizeof (version));
18:44:17 GMT <markuman> I hate C so much :D
18:59:03 GMT <minus> :)
19:06:21 GMT <minus> dvirsky_: there https://github.com/antirez/redis-doc/pull/726
19:16:47 GMT <dvirsky_> cool. I don't have push permissions to this though. antirez?
19:17:16 GMT <minus> fancy (and complicated) system for the docs there
19:21:55 GMT <markuman> hm, how to convert/cast RedisModuleString argv[1] to 'const char *'?
19:31:38 GMT <markuman> okey, got it. RedisModule_StringPtrLen ()
19:40:33 GMT <markuman> https://github.com/neomantra/redis-mod_luajit lol
21:01:45 GMT <antirez> Thanks for the PR, just merged.
21:03:01 GMT <minus> nice nice
21:03:11 GMT <minus> does it auto-deply to redis.io?
21:04:18 GMT <antirez> no I just deployed manually (I need to type the name of a script and it does all the work)
21:04:42 GMT <minus> fair enough
21:43:09 GMT <goldstar1> hmm, I would like to get involved in the redis project
21:43:26 GMT <goldstar1> been using it for the past 4 years; would like to give back
22:16:10 GMT <ahfeel> I just had a very annoying almost downtime of my production on a quite high traffic website because redis was sometimes VERY slow to connect.. even the redis-cli locally would hang like 20 seconds before connecting
22:16:34 GMT <ahfeel> I just restarted everything and it worked again, but I tried to diagnose in a lots of way and couldn't find the root cause
22:16:47 GMT <ahfeel> it's the first time it happens to us :|
22:17:04 GMT <ahfeel> antirez: do you have an idea about how to diagnose this if it happen again ?
22:19:34 GMT <crystal77> Any simple way to delete the oldest 20% of keys?
22:41:21 GMT <goldstar1> ahfeel: sounds like a possible network issue? you could strace the process to see what its doing that the time
22:41:31 GMT <goldstar1> at that*