This version (2017/05/27 13:44) is a draft.
Approvals: 0/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 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

[16:44:44] <temporalfox> reactive-streams is diffevent

[16:44:51] <temporalfox>

[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> 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:

[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