Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1456354800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:04:38] <​jtruelove_>​ temporal_ kabam!! -> https://​github.com/​eclipse/​vert.x/​pull/​1315
 +
 +[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 https://​github.com/​cescoffier/​vertx-cache. 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: https://​groups.google.com/​d/​msg/​vertx/​DeOb71IhE2g/​JYbR1vTP8_cJ ?
 +
 +[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_>​ github.com/​cyngn/​vertx-util
 +
 +[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