[13:57:34] <ewittman> temporalfox, vertx question (not related to the reverse proxy project, but rather a different one I'm working on)
[13:57:45] <temporalfox> hi ewittman
[13:57:53] <ewittman> temporalfox, good afternoon :)
[13:57:56] <temporalfox> indeed
[13:58:01] <temporalfox> good morning then
[13:58:05] <temporalfox> what is the question ?
[13:58:26] <ewittman> temporalfox, is there a way to route incoming http requests to specific instances of a verticle?
[13:59:11] <ewittman> temporalfox, for example, if the request is a REST call and included some sort of ID - requests related to that ID could always be routed to the same verticle instance
[13:59:46] <temporalfox> what do you mean by instance ?
[13:59:48] <temporalfox> instances of the same verticle class
[13:59:56] <ewittman> yes exactly
[14:00:11] <temporalfox> what would be the purpose ?
[14:00:20] <temporalfox> you want to sticky ness of the state ?
[14:00:21] <ewittman> the idea is to eliminate the need for synchronization
[14:00:32] <temporalfox> to/some
[14:01:20] <temporalfox> so the verticle instance maintain some state that client relies on ?
[14:01:38] <temporalfox> for that client
[14:01:47] <ewittman> not pinned to the client, no
[14:01:56] <ewittman> imagine a REST server that managed a number N of object Foo
[14:02:02] <ewittman> where Foo had some state that could be mutated
[14:02:19] <ewittman> And multiple clients could attempt to mutate any of the Foos
[14:02:42] <ewittman> With a single verticle instance, there's no need to synchronize anything (not the list of Foos, nor each individual Foo)
[14:02:54] <ewittman> But with multiple verticles, obviously we need to synch on both those things.
[14:03:00] <ewittman> Correct?
[14:03:05] <temporalfox> that's why usually you use sharedData
[14:03:10] <temporalfox> and vertx provides that
[14:03:22] <bgeorges> Hi temporalfox
[14:03:26] <temporalfox> hi bgeorges
[14:03:45] <bgeorges> How is life in retail sector temporalfox
[14:04:19] <temporalfox> bgeorges actually I don't know , you're pinging the wrong person I think
[14:04:34] <temporalfox> if you have issues with synchronization between the Foo's
[14:04:38] <bgeorges> temporalfox: Yes, I got confused :)
[14:04:46] <temporalfox> you can accumulate state in each foo
[14:04:51] <temporalfox> and periodically merge the Foo's state in a single Foo
[14:05:05] <temporalfox> if that's what you want to do
[14:05:14] <temporalfox> i.e you batch
[14:05:55] <ewittman> hm - i'm trying to imagine how that would work in this case
[14:05:57] <temporalfox> bgeorges n/p it happened to others in the past
[14:06:20] <temporalfox> I don't know what are you business data ewittman
[14:07:15] <ewittman> sure - i'm working on a rate limiting micro-service, which is basically just a REST server that manages N “rate limits” where a rate limit is a counter with a max value and a reset time
[14:07:22] <bgeorges> temporalfox: I can believe that :)
[14:07:51] <ewittman> so, temporalfox, lots of clients would be trying to increment multiple rate limits (counters) very often
[14:08:26] <ewittman> so lots of requests spread across multiple counters, all trying to increment them until the rate is reached
[14:08:37] <ewittman> *until the limit is reached
[14:08:49] <temporalfox> is it an hard limit ?
[14:08:54] <ewittman> yes
[14:09:04] <temporalfox> or can you tolerate a few more ?
[14:09:23] <temporalfox> I see, so you cannot do batch
[14:09:55] <ewittman> what I have now is a single-verticle implementation that simply manages the rates in memory and doesn't use any synchronization when doing the rate limit logic
[14:10:00] <temporalfox> it means that you need to synchronize indeed
[14:10:01] <ewittman> and it works great and performs very well
[14:10:07] <temporalfox> how do you synchronize at the moment ?
[14:10:11] <temporalfox> compare and swap ?
[14:10:25] <temporalfox> have you tried with AtomicFieldUpdater ?
[14:10:41] <ewittman> no synchronization at the moment - only using a single verticle so there's only ever one thread modifying the rates
[14:10:54] <temporalfox> ok
[14:10:55] <ewittman> there's very little logic so a single thread can process a lot of rates
[14:11:03] <ewittman> something like 10k per second right now
[14:11:04] <temporalfox> if it's just a counter, there is an efficient class for that
[14:11:06] <temporalfox> in java 8
[14:11:10] <temporalfox> LongAdder
[14:11:28] <temporalfox> it's designed for this purpose I think
[14:11:36] <ewittman> yes - we are going to create an implementation using ConcurrentHashMap (for the collection of rate limits) and something like AtomicLong for the counter
[14:12:12] <ewittman> but I was just thinking that if a rate limit could be “pinned” to a verticle instance, then we'd be back to not needing any synchronization at all
[14:12:27] <temporalfox> no you cannot do that
[14:12:27] <ewittman> if vertx had something for that then I thought we'd give BOTH impls a try and see which one was faster :)
[14:13:10] <ewittman> http request routing to verticle instances is done how? round robin?
[14:13:23] <temporalfox> it is per connection
[14:13:38] <ewittman> ah interesting
[14:13:53] <temporalfox> when a client connects, it is assigned an handler
[14:14:07] <temporalfox> so you can have multiple requests hit the same handler
[14:14:13] <temporalfox> if they use the same connection
[14:14:39] <ewittman> ok understood - so that definitely makes it hard/impossible to route per-request based on state in the request
[14:15:48] <ewittman> temporalfox, OK thanks! We'll see how the synch impl compares to the single-verticle impl (on an 8 core server)
[14:16:20] <temporalfox> the problem you will have does not actually depend on vertx
[14:16:27] <temporalfox> it's more a mechanical sympathy thing
[14:16:46] <temporalfox> and concurrency between cores
[14:17:17] <ewittman> ooo - not sure what that means… can you explain a bit?
[14:22:50] <temporalfox> I mean that your problem is to share state between threads
[14:22:55] <temporalfox> efficiently
[14:23:15] <temporalfox> and AtomicLong seems what you need to use
[14:23:29] <temporalfox> and you should check it works good enough for you
[14:23:57] <ewittman> right - we're absolutely going to do that and check the results
[14:24:48] <ewittman> I wouldn't even consider attempting something else, except that the reset logic (the rate limit resets to 0 at a particular moment in time) does require some additional thread coordination
[14:25:09] <ewittman> Although it's not a huge deal, and standard java 8 concurrency approaches will likely be just fine
[14:25:22] <ewittman> I was just looking for another approach to test :)
[14:27:41] <ewittman> temporalfox, thanks again - and in other news, I'll have a PR for you today on the reverse proxy project - you can tell me if any of my changes are useful :)
[14:28:05] <temporalfox> ewittman sure I'll do
[14:43:47] <ewittman> temporalfox, https://github.com/vietj/vertx-reverse-proxy/pull/1
[14:44:26] <temporalfox> thanks ewittman will have a look soon!
[14:44:44] <ewittman> temporalfox, no rush, really
[16:43:03] <Sticky_> does anyone know, does the callback on “put” for a cluster wide AsyncMap, is that called when every cluster member has accepted the new value? Or is it something weaker like the local map has been updated?
[18:37:36] <JordyBaylac> I have some question here https://groups.google.com/forum/?fromgroups#!topic/vertx-dev/BGJq0UV-OzY
[19:29:38] <temporalfox> hi, this is the wrong google group
[19:30:01] <temporalfox> he left already
[21:24:33] *** ChanServ sets mode: +o temporal_
[22:17:36] <AlexLehm> temporal_: it is so anooying that freenode doesn't have a offline msg function by default
[22:17:46] <temporal_> AlexLehm hi
[22:17:47] <temporal_> why ?
[22:17:51] <temporal_> there is vertx-dev for this
[22:18:13] <temporal_> or twitter
[22:18:36] <AlexLehm> i mean when somebody is in the channel and asks a question and leaves after 10 minutes, i would prefer to be able to send a msg
[22:18:57] <temporal_> ah yes
[22:19:02] <temporal_> good point
[22:32:14] <AlexLehm> there is a offline messaging function in freenode, but it only works for authed users that have activated it, so its not helpful for users that are new
[22:32:40] <AlexLehm> otoh, when somebody only logs in once into irc, they will not get the offline message anyway