Differences

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

@@ Line 1: / Line 1: @@
+[10:52:02] <skullcrasher> what is best practice for messaging with vertx? would you register a service on one adress and add headers for the action the service should perform or make the address explicit like my.service.action1
+[10:52:23] <skullcrasher> and just send your content as message to this addres
+[10:55:20] <pmlopes> @skullcrasher if you use explicit addresses then you don't need to do any processing all is handled by the eventbus, it also gives you decoupling so in theory you can easily scale specific actions by deploying more action nodes in to the cluster
+[10:57:39] <skullcrasher> ok. 2nd is what we have now
+[10:58:45] <skullcrasher> we just have one problem with this right now.
+[11:00:04] <skullcrasher> we have 1 service that has to call several other services (which are dynamic)
+[11:00:18] <skullcrasher> basically what I try to do is a publish with reply
+[11:02:01] <skullcrasher> the services that should be called do have to take the same actions, just on different entities and reply that.
+[11:02:43] <skullcrasher> I now thought on let them register with the one service, with their respective adresses
+[11:03:18] <skullcrasher> and just call them in a loop with "send" so they all can reply and use a completable future to wait for all of them (or timeout)
+[11:04:54] <skullcrasher> is this the right mindset?
+[12:45:03] <pmlopes> @skullscrasher yes, i'd not use a publish since if you have more than 1 instance of a action deployed they all get called, I'd send a message to all required addresses and with a completable future/loop what you think is easy for you collect all replies and return
+[13:07:50] <skullcrasher> pmlopes, thx :)
+[19:54:53] *** ChanServ sets mode: +o temporalfox
+[20:21:13] *** ChanServ sets mode: +o temporalfox
+[20:44:16] *** ChanServ sets mode: +o temporalfox
+[21:16:22] *** ChanServ sets mode: +o temporalfox