03:30:04 GMT <edge226> Hello, When I run the info command. The data sent back does not follow the resp protocol, Does anyone know why?
07:55:28 GMT <badboy_> edge226: weeell, it still is in the RESP protocol, it is just a big string ^^
07:56:18 GMT <badboy_> edge226: it's for legacy reasons. In the beginning there was no RESP, so a simple and easy to parse plaintext format was used for INFO
14:12:24 GMT <film4242424242> Just had a question about the "{}" hash tags in redis cluster. Twemproxy allows this to be configurable. This is a very simple patch to the server, but it seems that every cluster client would need to be changed. Still, I'm just wondering if anyone else has asked about this or not. I've searching as much as I can, but it doesn't seem like the question has been raised. I figured I'd check here before opening an issue.
14:46:15 GMT <badboy_> aaand what was the question again?
14:47:36 GMT <film4242424242> My question is people are open to making hash tags configurable? If not, just wondering what the conversation was around locking that down.
15:06:50 GMT <badboy_> So I looked it up in Twemproxy. They allow to configure which characters to use to identify the part in a key name used for calculating the hash
15:07:01 GMT <badboy_> film4242424242: and your question is whether Redis should allow that as well?
15:07:08 GMT <film4242424242> Correct.
15:08:24 GMT <badboy_> I doubt it
15:08:39 GMT <badboy_> what's the benefit of it besides making it all more complicated?
15:13:25 GMT <film4242424242> badboy_: I figured since redis cluster is something you use once you've used sentinel as an option, it's nice if you can configure a few things. I was testing redis cluster and found one of our libraries is using {} in the keys. Simple library change, sure. But I was hoping redis cluster would be a bit more flexible.
15:14:25 GMT <badboy_> Hm, so mainly legacy reasons, I get that point
15:14:35 GMT <badboy_> I still don't think it would be added
15:17:50 GMT <film4242424242> I don't think it's "legacy" but since redis cluster is such a paradigm shift, it would be nice to set the hash tag characters. Since redis cluster has a certain amount of hidden complexity, it would be nice to control some of that. In other words, since I can control the partitioning of my keys, it would be nice to control the delimiters as well.
15:18:57 GMT <badboy_> Implement it, send a PR and wait 1-4 years and there you go (sorry for the sarcasm)
15:19:16 GMT <film4242424242> Haha, no it's fine. I get it.
15:20:02 GMT <film4242424242> If you don't mind me asking, why do you think it shouldn't be added?
15:20:57 GMT <film4242424242> Btw, I'm not asking to argue or anything. I'm just interested in the philosophy.
15:24:05 GMT <badboy_> I just think that making each and every little detail configurable leads to a lot more complexity
15:24:37 GMT <badboy_> especially if you do consulting and support of Redis ;)
15:26:05 GMT <badboy_> and teaching _one_ thing is far easier ("if you put it in brackets it will be a 'hash tag'" vs. "if you put it in brackets or whatever else you configured, ..., also you will always need to check the config when looking at data in another instance first")
15:27:37 GMT <film4242424242> Yeah. Having to configure that in two places is sure to cause many headaches. Same with a custom hashing alg like twemproxy let's you set. In their situation they're the only ones partitioning keys though, so it makes sense for them.
15:28:10 GMT <film4242424242> Thanks badboy_ for answering my questions! I really appreciate it :)
15:37:00 GMT <badboy_> you're welcome
15:50:16 GMT <Siecje> Is it possible to tell what is connected to redis? I'm getting max number of clients and I see the last commands are publish but redis won't accept anymore connections.
15:50:28 GMT <badboy_> INFO clients
15:50:37 GMT <badboy_> CLIENT LIST
15:50:54 GMT <badboy_> (obviusly you need a connection to send those commands)
15:57:11 GMT <Siecje> How can I track down which process is creating the connection?
15:59:54 GMT <minus> lsof probably
16:11:20 GMT <Siecje> lsof doesn't show me ports that large. largest one is < 2000
17:07:20 GMT <edge226> @badboy_ I figured that out last night and resolved it. Thanks for the info though :D
18:37:02 GMT <arthurl> hi guys- any issues w/ doing redis replication from 2.4.10 to 2.8.4 ?
18:37:45 GMT <GNU\colossus> I've never tried in practise, but when we upgraded from 2.4 to 2.8, people in this channel told me that was impossible
18:38:03 GMT <minus> you should probably upgrade to 3.2.9
18:38:11 GMT <minus> you're years behind
18:40:26 GMT <arthurl> GNU\colossus were you able to successfully upgrade from 2.4 to 2.8 without any major hurdles?
18:40:33 GMT <arthurl> minus that's the gameplan- one step at a time for us though :)
18:40:49 GMT <GNU\colossus> arthurl, just make the 2.8 servers load the 2.4 instances RDB, and you're good to go
18:41:09 GMT <GNU\colossus> I don't think it's a wise decision to upgrade to 2.8 and then go to 3.x from there
18:41:25 GMT <GNU\colossus> straight to 3.x is gonna be the same amount of effort, but only once
18:42:59 GMT <arthurl> gotcha
18:43:38 GMT <arthurl> is application backwards compatibility guaranteed on major version upgrades?
18:44:18 GMT <minus> afaik yes, but read the changelogs
18:45:47 GMT <arthurl> issue is that we are on a super old rhel 5.4 box on which the 2.4 redis is running
20:39:19 GMT <alukach> I'm trying to monitor a Redis List that is operating as a queue. Basically, when a new message is entered into the queue, I want to add it into a SQL DB. I originally tried with "Subscribe" but the problem is that subscribe simply notifies that something was written to the key, however it doesn't report WHAT is written. If I try to read the item from the list, I run the risk of missing the item as other processes are watching the queue for work and poppin
20:39:19 GMT <alukach> g from the list as soon as they can
20:39:26 GMT <alukach> Any suggesting on how I can get around this?