Differences

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

Link to this comparison view

irc:1466373600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[04:32:48] <​namrood>​ Anyone here, I can't build vert.x (main repo) locally, any tips?
 +
 +[11:19:07] <​skullcrasher>​ namrood, some more info would be nice, I guess
 +
 +[13:55:51] <​AlexLehm>​ namrood: the 3.3.0-SNAPSHOT should build with maven 3.3, there may be some unit tests failing depending on your system or environment
 +
 +[13:56:16] <​AlexLehm>​ it does or it did a few days ago for me even on windows
 +
 +[14:00:27] <​baris>​ hello all
 +
 +[14:01:37] <​baris>​ Although I have already set a custom configuration file that disables tcp-ip and multicast and enables aws
 +
 +[14:02:08] <​baris>​ The configuration is still the default one.
 +
 +[14:02:20] <​baris>​ DO you have any clue?
 +
 +[14:52:19] <​cescoffier>​ baris: your configuration must be named "​cluster.xml"​ and be at the root of your classpath
 +
 +[15:35:11] <amr> enables aws?
 +
 +[15:50:22] <​pouyanster>​ n00b here: got a question regarding sending mssages over the bus while handling a received message
 +
 +[15:51:14] <​pmlopes>​ what is the question then? :)
 +
 +[15:51:26] <​pouyanster>​ I've got a Handler registered for a specific address and upon receiving msgs I want to send further messages, aggregate the replies and send a reply
 +
 +[15:52:08] <​pouyanster>​ I came to understand that any eventBus.send invokations inside a handler actually take effect *after* the handler returns
 +
 +[15:52:25] <​pouyanster>​ I wanted to know if I've got it right?
 +
 +[15:53:56] <​pouyanster>​ In other words if Inside a handler, I send further messages, I cannot block the handler and wait for replies of those messages
 +
 +[15:56:19] <​pouyanster>​ sorry, I'm talking about the Java API
 +
 +[15:56:29] <​temporalfox>​ pouyanster yes you cannot block
 +
 +[15:56:38] <​temporalfox>​ blocking is not reactive
 +
 +[15:57:01] <​temporalfox>​ what you should do is wait for replies from your messages and in these replies possibly send a reply to the original message
 +
 +[15:57:09] <​pouyanster>​ temporalfox I start my verticle as a worker one not to block the bus
 +
 +[15:57:29] <​temporalfox>​ that's not a good idea
 +
 +[15:57:42] <​pouyanster>​ temporalfox:​ indeed.
 +
 +[15:57:43] <​temporalfox>​ you should use worker if you are using a blocking API
 +
 +[15:58:01] <​temporalfox>​ like using an java.net.URL get resource
 +
 +[15:58:15] <​pouyanster>​ the verticles make REST calls over the net
 +
 +[15:58:26] <​pouyanster>​ thats why I thought a worker is suitable
 +
 +[15:59:05] <​pouyanster>​ and I send messages to two verticles which make REST GET calls, and I want to make a reply as soon as these two have sent a reply
 +
 +[15:59:17] <​pouyanster>​ and here comes the synchronization problem
 +
 +[16:00:11] <​pouyanster>​ in summation: there'​s a verticle that sends messages to two other verticles (which fetch data over internet) and aggregates the replies to compose its own reply
 +
 +[16:27:31] <​temporalfox>​ yes you should not block
 +
 +[16:27:44] <​temporalfox>​ pouyanster looks a composition of reactive blocks
 +
 +[16:32:20] <​pouyanster>​ @temporalfox I think I am thinking too much in conventional java terms. I suppose rxvertx module can help me with this.
 +
 +[16:34:01] <​pouyanster>​ make two observables for each bus-send and wait for both to succeed
 +
 +[16:39:25] <​pouyanster>​ Or this for Vertx3 http://​vertx.io/​docs/​vertx-reactive-streams/​java/​
 +
 +[16:44:44] <​temporalfox>​ reactive-streams is diffevent
 +
 +[16:44:51] <​temporalfox>​ https://​github.com/​vert-x3/​vertx-rx
 +
 +[16:45:01] <​temporalfox>​ we do have in Vert.x core : CompositeFuture
 +
 +[16:45:04] <​temporalfox>​ you may want to look at it
 +
 +[16:45:19] <​temporalfox>​ it seems to solve the basic composition you seem to have
 +
 +[16:45:50] <​temporalfox>​ http://​vertx.io/​docs/​vertx-core/​java/#​_async_coordination pouyanster
 +
 +[16:48:47] <​pouyanster>​ @temporalfox I already read that. But had problems grasping how to combine my handlers for each send using a composite future. Please excuse my lack of research. I think this can also help me: http://​vertx.io/​docs/​vertx-rx/​java/​
 +
 +[16:49:01] <​temporalfox>​ yes that too
 +
 +[16:49:03] <​temporalfox>​ depends on your style :-)
 +
 +[16:49:04] <​pouyanster>​ Next time, ill take more time for research before asking. thanks
 +
 +[17:18:33] <​pouyanster>​ Ok I got it now! Similar to JS futures, I just create futures that I complete when I receive the replay for each bus-send. I combine them using the CompositeFuture and voila! seems cleaner to me than JavaRx
 +
 +[17:58:38] <​temporalfox>​ pouyanster for simple cases yes
 +
 +[17:59:01] <​temporalfox>​ pouyanster RxJava can be very powerful too but for such thing it's ok to use composite future
 +
 +[17:59:09] <​temporalfox>​ i;e composite future don't aim to replace rxjava in its use cases :-)
 +
 +[18:11:09] <​pouyanster>​ temporalfox I have some Rx experience in JS and Python and have learned to be really carefull with it, as it can get really complicated really fast :D
 +
 +[18:35:28] <​pouyanster>​ thanks! it has been a great help. problem is no solved!
 +
 +[23:19:28] <​temporalfox>​ hi AlexLehm
 +
 +[23:37:17] <​AlexLehm>​ Hello Julien
 +
 +[23:37:34] <​AlexLehm>​ have is the release coming along?
 +
 +[23:40:17] <​AlexLehm>​ how is ...
 +
 +[23:40:33] <​AlexLehm>​ maybe i should pay more attention when typing