07:36:40 GMT <jen> hello everyone
07:36:45 GMT <jen> i've a question
07:37:02 GMT <jen> using pub/sub, is posible to broadcast only yo one subscriber?
07:37:17 GMT <jen> only to*
07:38:24 GMT <jen> In a context where there may be multiple subscribers
08:46:15 GMT <badboy_> jen: the whole idea of `broadcast`ing is ... well, broadcasting, isn't it?
08:46:34 GMT <badboy_> so no, published messages will always be send to all subscribed clients of that channel
10:31:17 GMT <inersha> I've written a script that constantly pushes the latest visitor IP addresses on to a list. I want this to be a "daily" list. Would the simplest way to do this be to set a cron job to delete the list at the start of every day?
10:32:32 GMT <inersha> I would actually prefer the list to be for the past 24 hours, but not sure how to achieve that using EXPIRE.
10:34:48 GMT <badboy_> a moving window of 24h?
10:35:01 GMT <badboy_> use a sorted set with score=timestamp and remove old values?
10:40:03 GMT <ahfeel> inersha: You can use a list per day (or a set to avoid duplicates), with the date being in the set key
10:40:30 GMT <ahfeel> this works for the first usecase, not the 24h window
10:40:50 GMT <ahfeel> for a 24h window, badboy's suggestion is probably the best
10:42:17 GMT <inersha> ahfeel, @badboy: Thanks
10:43:09 GMT <inersha> @badboy: What if I have been setting an increment counter as the score, so I cannot use a timestamp in the score?
10:43:31 GMT <inersha> So basically, the list is "IPs with the most visits over the last 24 hours"?
11:22:56 GMT <minus> jen: if you want one recipient, use a list in redis and brpop on it from multiple clients
14:56:01 GMT <c2nes> Hey all. I'm trying to vet Redis cluster for use at my company and I'm running into some issues when I start stressing slot migration
14:56:30 GMT <c2nes> tl;dr it seems really easy to get the cluster into an inconsistent state with nodes disagreeing about slot ownership
14:56:43 GMT <c2nes> data loss usually comes with this as well
14:57:19 GMT <c2nes> the test I'm running involves migrating a slot between two instances, back and forth
14:58:19 GMT <c2nes> I'm fairly certain the slot migration code is consistent with redis-trib, but it seems like running the migrations too quickly (> ~1 per second) quickly leaves teh cluster in the bad state
14:59:20 GMT <c2nes> I've tried inserting code that waits for the slot mapping to stabilize across the cluster between migrations, but this seems to be insufficient without including long pauses as well
15:00:21 GMT <c2nes> Is this just expected? I can't seem to find any documentation or anything that describes exactly how to perform these operations safely
15:15:19 GMT <badboy_> c2nes: in theory, waiting for the migration to stabilize should do the trick
15:15:36 GMT <badboy_> (but I had some edge cases where it seemed like I could trigger inconsistencies as well)
15:15:43 GMT <badboy_> (some time ago...)
15:28:15 GMT <c2nes> badboy_: do you know what indicates that the cluster has stabilized after a migration? I've been using a check that waits until CLUSTER NODES reports consistent slot ownership across all nodes and this doesn't seem to be sufficient
18:05:33 GMT <elmo_> Hi @here
18:05:43 GMT <elmo_> Quick question.
18:06:15 GMT <elmo_> Redis is bind on 0.0.0.0 when launched with default config.
18:06:19 GMT <elmo_> binding.
18:06:53 GMT <elmo_> Does that mean that redis is able to use a zeroconf IP address (APIPA) network?
18:09:05 GMT <Mr__Anderson> quick answer.... true for any service, not just for redis.... going on listen on 0.0.0.0 automatically implies that you are listening on any address available on the host..... current or future
18:09:27 GMT <Mr__Anderson> so, whenever an interface will be brought up, APIPA or not
18:09:45 GMT <Mr__Anderson> the service will be automatically listening on it
18:10:53 GMT <elmo_> yes, I know, but sometimes, software developers just decide to deny any APIPA class or use some weird IP block verification algorythme not taking care of APIPA land ^^ so I asked before pushing further time on the redis software
18:11:12 GMT <elmo_> ok, many thanks for your time and information.
23:55:30 GMT <RandalSchwartz> just reviewing various things in preparation of Tague Griffith coming on my show on Wednesday (twit.tv/floss)