08:49:31 GMT <prashanthraghu> hello
08:49:36 GMT <prashanthraghu> my name is prashanth raghu
08:49:44 GMT <prashanthraghu> i had a doubt on the design of redis
08:49:49 GMT <prashanthraghu> for the event loop
08:50:03 GMT <prashanthraghu> could libuv have been an alternative
08:50:07 GMT <prashanthraghu> to ae
08:50:12 GMT <prashanthraghu> if no
08:50:17 GMT <prashanthraghu> can someone explain to me
08:52:41 GMT <prashanthraghu> i'm asking this question because i see ae and libuv as equivalents
09:01:50 GMT <badboy_> yes
09:02:11 GMT <badboy_> in theory every event loop implementation would have done
09:19:01 GMT <prashanthraghu> can someone explain to me
09:19:05 GMT <prashanthraghu> when this function is used
09:19:16 GMT <prashanthraghu> clusterBroadcastMessage
09:19:17 GMT <prashanthraghu> ??
09:24:32 GMT <badboy_> when broadcasting a message for all cluster participants
13:09:14 GMT <battousai> can i do a command, for example llen for each return key from lrange without external scripts ?
13:13:49 GMT <minus> battousai: take a look at EVAL
13:23:03 GMT <battousai> minus: thank you very much
15:21:42 GMT <prashanthraghu> hello good morning
15:21:45 GMT <prashanthraghu> can i know
15:21:48 GMT <prashanthraghu> what is a zipmap
15:21:49 GMT <prashanthraghu> ??
15:22:32 GMT <prashanthraghu> how is it more memory efficient
15:22:44 GMT <prashanthraghu> are operations on it as well O(1)
15:22:45 GMT <prashanthraghu> ??
15:23:20 GMT <badboy_> it's documented here: https://github.com/antirez/redis/blob/unstable/src/zipmap.c#L43-L76
15:25:21 GMT <badboy_> also: please refrain from using multiple successive punctuation marks, it is considered rude and doesn't add any additional information to your requests ;)
15:25:32 GMT <prashanthraghu> okay sure
15:25:45 GMT <prashanthraghu> kind of a habit here in India
15:27:29 GMT <prashanthraghu> did not know it's rude
15:28:05 GMT <badboy_> Don't worry
15:28:31 GMT <minus> to me it seems immature and impatient, and i'll more likely just ignore you because of it, dunno if that's the same for other people, but i guess so
15:29:16 GMT <prashanthraghu> minus: As i said it is not intentional
15:29:24 GMT <prashanthraghu> more so like a habit in india
15:29:43 GMT <prashanthraghu> but I am sure it will not happen again
16:56:51 GMT <gitgud> anyone around?
17:08:01 GMT <badboy_> maybe. maybe not.
17:12:18 GMT <etehtsea> badboy_ since you are here... sorry for disturbing, but I would be happy if you'll find time to merge this https://github.com/antirez/redis-doc/pull/791  thank you!
17:13:54 GMT <badboy_> done
17:25:22 GMT <etehtsea> badboy_ thank you again!
17:56:44 GMT <etehtsea> badboy_ seems that something went wrong :) I don;t see any changes
17:59:36 GMT <badboy_> not sure when it will appear
17:59:41 GMT <badboy_> I have no control over the deployment ;)
18:00:26 GMT <etehtsea> badboy_ I mean PR is still open. Is it ok?
18:00:34 GMT <badboy_> is it?
18:00:41 GMT <badboy_> oh well
18:00:44 GMT <badboy_> github...
18:01:04 GMT <badboy_> now it's merged
18:01:37 GMT <etehtsea> awesome, thanks you :)
18:26:16 GMT <gitgud> i wanted to ask a question to someone who knows the answer but i already asked it 2 days ago so i'm going to quote it here. if anybody knows then pleace respond that would be great
18:26:19 GMT <gitgud> please*
18:26:42 GMT <gitgud> ah the question is lost in my logs. guess i'll have to ask it again
18:27:52 GMT <gitgud> to someone who is familiar with the *-lru policy. how does lru manage memory in the case of when say the entered value is say 2kb and the least recently used  is say 1kb. the last last one is say 2kb. does that mean that both of those get removed? how does redis handle this situation?
18:30:50 GMT <gitgud> sorry if my question is not clear. basically, how does redis handle the situation where the eviction candidate space is not enough for the next big object to be inserted?
18:32:44 GMT <gitgud> badboy_, do you know the answer to this one? :p
18:33:32 GMT <badboy_> 1. lru is approximately
18:36:25 GMT <badboy_> afaik in your case if it deletes the 1kb it sees that used memory < maxmemory and would insert the new value
18:36:37 GMT <badboy_> thus over-allocating by ~1kb over your maxmemory setting
18:49:19 GMT <gitgud> badboy_, ah i see. so in the case of where the last 2 objects dont even make up space for the new object then those 2 obects would be removed too yeah?
18:51:22 GMT <badboy_> https://github.com/antirez/redis/blob/unstable/src/evict.c#L376
18:51:29 GMT <badboy_> it only tries to free enough to go below the limit
18:51:52 GMT <gitgud> ah cool! that solves my problem
18:53:04 GMT <gitgud> thanks badboy_
20:03:03 GMT <steeze> I'm getting this error intermittently: Failed to connect to redis: php_network_getaddresses: getaddrinfo failed: System error
20:03:27 GMT <steeze> if it wasn't intermittent i'd think there was an issue with my hostname or ip address setup, but it's not consistent so i'm not sure what could be causing it
20:32:00 GMT <rfer> steeze, flaky dns
20:32:06 GMT <rfer> persistent connection times out right as you query
20:32:40 GMT <rfer> which happens quite often in practice, which is why retries and idempotence are important in network requests
20:33:44 GMT <minus> retries? what is that =D
20:34:00 GMT <steeze> rfer odd. i dont think ive ever had this issue before. any idea of the root cause?
20:34:11 GMT <steeze> just my servers being whacky for a bit?
20:34:16 GMT <rfer> your sysadmin sucks at setting up dns
20:34:38 GMT <rfer> or the connection expires between the time between a thread checking if a connection is still valid and using the connection
20:34:51 GMT <steeze> LOL
20:35:08 GMT <rfer> one of the two is fixable
20:35:39 GMT <steeze> im leaning towards the latter just because ive never had this issue before and we've been running on this infrastructure for months
20:35:52 GMT <minus> your sysadmin sucks? i know that feeling
20:35:56 GMT <steeze> lol
20:36:08 GMT <steeze> it's an amazon EC2 instance
20:43:08 GMT <steeze> rfer is there a way for me to debug a dns issue like this/
20:44:33 GMT <rfer> i have no idea. there's also other possible error cases.
20:44:48 GMT <rfer> e.g. you managed to eat up all your file descriptors so a new socket can't be opened
20:44:51 GMT <steeze> word, i mean *a possible dns issue like this
20:45:02 GMT <rfer> which would be the developer's fault
20:45:44 GMT <steeze> how would that happen?
20:45:58 GMT <rfer> idk, you could just spam nslookup in a command line and see if you get errors sometimes
20:46:34 GMT <rfer> idk how php works because i've been told it's cancer, but if for example you closed a connection but the underlying library relies on garbage collection to clean up old sockets
20:46:45 GMT <rfer> and somehow you closed a ton of connections before the last GC run
20:47:10 GMT <steeze> interesting
20:47:13 GMT <rfer> or you're getting dropped connections because of a bad network or something, and your application keeps reopening those connections
20:47:19 GMT <steeze> okay thanks ill keep that in mind
20:47:23 GMT <rfer> and the old connections keep sitting in CLOSE/TIME_WAIT
20:47:51 GMT <steeze> hmm like from a super intensive data report that a team member might close out because it's taking too long?
20:48:29 GMT <rfer> dunno how your data report is generated so i can't say
21:41:49 GMT <steeze> i restarted my server and it seems to have resolved itself. worried this might happen again though
21:41:57 GMT <steeze> ¯\_(ツ)_/¯