This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[00:04:38] <jtruelove_> temporal_ kabam!! →

[03:41:06] * ChanServ sets mode: +o temporalfox [07:43:11] <pplcf> i'm trying to make stateful clustered application with vertx [07:43:22] <pplcf> I have some problems with fail over handling [07:43:42] <pplcf> since app is stateful I need to know on which vertx node user is running [07:43:55] <pplcf> and i'm using cluster wide map for that purpose(userId to nodeId) [07:44:06] <pplcf> but when one node crashes [07:44:22] <pplcf> hazelcast rebalances all shared data [07:44:38] <pplcf> so userId inside that map points to failed node [07:54:33] <pplcf> sorry, power failed [07:54:48] <pplcf> so, hazelcast rebalances all shared data [07:55:00] <pplcf> and userId keeps pointing to crashed node [07:55:42] <pplcf> and seems there is no way to get list of all values of shared map [07:55:47] <pplcf> or at least keys [07:56:29] <pplcf> am I doing something conceptually wrong? [08:04:28] <temporalfox> pplcf I think you cannot get the list of all keys because they are distributed [08:05:11] <temporalfox> pplcf are you doing some kind of sticky session with this construct ? [08:16:36] <cescoffier> pplcf temporalfox : I confirm, you can't have the key list on distributed map. [08:47:22] <pplcf> <temporalfox> yes, sort of sticky session [09:02:00] <cescoffier> pplcf : you can use a Cache API as It's a distributed cache providing an async version of JCache. You can get the keys. You can use it with any JCache provider (Hazelcast, Ignite…) [09:04:59] <pplcf> <cescoffier> I will have a look at it, thank you [11:36:52] <pplcf> so I decided to throw away shared map at all [11:38:15] <pplcf> and make special verticle to keep track of all users in local map [13:45:15] <cescoffier> pplcf: local map does not scale among several JVM (but you are probably aware of this) [18:26:17] <dns_> Hi there! Could someone please help me with chaining several http requests when each next request uses data from previous? If I not mistaking it is not possible to do with Futures, right? [18:32:41] <dns_> my example is a verticle which gets auth session from another one. First request to get license server. After that I submit login form with login and password and license server key from first request, etc.. [18:33:02] <dns_> from another one http service (remote server) [18:37:22] <AlexLehm> dns_: you can start the next request in the bodyHandler of the previous one, that should work for a few chained requests [18:39:22] <dns_> AlexLehm: Like here: ? [18:40:36] <AlexLehm> yes like that [18:40:53] <AlexLehm> if you have a more complicated sequence of requests, rx might be a good idea though [18:41:01] <AlexLehm> that makes error handling easier [18:42:08] <AlexLehm> ah, the example from the group is quite old, that is vertx 1.x i think, but the same solution is valid now [18:52:03] <dns_> Is comment from Tim Fox still actual?)) [18:52:11] <dns_> by* [19:24:25] <jtruelove_> dns_ if you are interested vertx-util has async latches and a simple promises impl that lets you easily coordinate N events then do something after they are succeed or there is a failure [19:25:13] <jtruelove_> [19:26:50] <dns_> jtruelove_: thank you! going to explore it! [19:28:14] <jtruelove_> i wrote these things for simplifying the type of coding you are trying to do, pretty common pattern in JS & async in general [19:37:46] * ChanServ sets mode: +o temporalfox