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

[12:21:46] <BadApe> hello, I would like to eb.publish(“get.all.data”, jsonQuery, response → { did i get a response from everyone listening? }

[12:23:01] <BadApe> basically i want to be able to process the response from every listener i published to

[13:46:36] <bendh1> Hello, I'm currently evaluating vert.x as a candidate for a reactive architecture. One of the question that popped out where - Is there any commercial support available (Possibly with SLA)?

[14:38:30] <temporalfox> bendh1 there isn't any commercial offering as of today, vert.x is an eclipse project

[14:39:38] <temporalfox> BadApe what is your actual question ?

[15:48:03] <BadApe> temporalfox, what i wanted to know was how can i process the response from an eventbus publish, ideally i want to aggregate the responses into one

[15:48:35] <temporalfox> BadApe you need to publish a message and set a timer for accepting responses

[15:48:44] <temporalfox> you accept only the response befor ethe timer

[15:48:48] <temporalfox> or mayne a threshold

[15:49:06] <temporalfox> like after 10 responses or 20 seconds I consider I have all the results

[15:49:08] <temporalfox> (configurable)

[15:49:19] <temporalfox> another option is to have the other parties ping your periodically

[15:49:25] <temporalfox> give you their address

[15:49:33] <temporalfox> and you can send a message to each handler

[15:50:59] <BadApe> i see, i think i will explore the timer first

[21:27:16] *** ChanServ sets mode: +o purplefox

[22:28:42] <pikajude> hello, when I use vertx.executeBlocking inside one of my handlers i start getting this exception: “java.lang.IllegalStateException: Request has already been read”

[22:28:44] <pikajude> from the BodyHandler

[22:28:56] <pikajude> if I instead inline the blocking code, the error doesn't happen

[22:28:57] <pikajude> why is this

[22:54:41] <temporalfox> can you give more details ?

[22:54:53] <temporalfox> I think there is a blocking handler in vertx web you case use that do that for you

[22:55:51] <pikajude> i moved BodyHandler to the top of the list and it works now

[23:00:28] <AlexLehm_> pikajude: maybe you have to pause the request before you start the blocking code

[23:01:44] <D-Spair> If he's trying to read a request in a blocking handler, he would have had to set the Route to expect multipart.

[23:01:56] <D-Spair> I hit this same issue a while back.

[23:02:41] <D-Spair> Wihtout setting expectMultipart BEFORE the blockingHandler, the blockingHandler is not able to handle the multipart body.

[23:06:25] <temporalfox> make sense

[23:07:22] <pikajude> well, i'm not trying to read the request, unless headers count

[23:07:28] <D-Spair> What I had to do was use a non-blocking handler which sets the expectMultipart and then pass th request to an executeBlocking handler.

[23:09:00] <D-Spair> pikajude: Then you're doing something I haven't tried… Let's ask the pertinent question: At a high level, what are you trying to accomplish?

[23:09:49] <D-Spair> There may be a more “vert.xy” way to do it.

[23:11:08] <D-Spair> The only reason I have found so far to drop into blocking code is for libraries which do not support non-blocking… In my case it was interacting with an LDAP server.

[23:18:29] <pikajude> D-Spair: auth handler that calls an external service to validate a token

[23:18:54] <D-Spair> IS the external service accessed via HTTP?

[23:19:01] <pikajude> yea

[23:19:11] <D-Spair> Then why not use the non-blocking HTTP client?

[23:19:22] <D-Spair> That's what I do for accessing Google OAuth.

[23:19:33] <pikajude> well, executeBlocking makes it non-blocking anyway

[23:19:41] <pikajude> idk what using the http client would accomplish

[23:19:54] <D-Spair> pikajude: Well, I will give you that, but it also makes it harder to integrate with the rest of Vert.x

[23:20:15] <pikajude> maybe

[23:20:21] <D-Spair> Using the Vert.x HTTP client would allow you to avoid using executeBlocking altogether.

[23:20:34] <pikajude> but it wouldn't make the handler synchronous which is the only way it succeeds currently

[23:21:14] <D-Spair> pikajude: My recommendation would be to create an implementation of “Handler<RoutingContext>” which uses the non-blocking HttpClient from Vert.x to validate the token versus the external service.

[23:21:39] <pikajude> ok

[23:21:43] <D-Spair> Then you can put that handler into your Router to cover all of your request paths.

[23:21:48] <pikajude> ok

[23:22:03] <pikajude> but it'll still be asynchronous right

[23:22:22] <D-Spair> More asynchronous than using executeBlocking…

[23:22:37] <pikajude> how is it “more” asynchronous?

[23:23:03] <D-Spair> Also, what sort of external auth service is it? Vert.x has modules for a lot of the major auth platforms like: pac4j, OAuth, JWT, Shiro, etc…

[23:23:12] <pikajude> it's none of those

[23:24:18] <D-Spair> pikajude: executeBlocking works by putting your code onto the default ThreadPoolExecutor… That has a limited number of available threads. Using the async HttpClient uses the Vert.x threads and async operations via epoll. That will never suffer from thread waits.

[23:24:46] <pikajude> that's my point though

[23:24:58] <pikajude> if the code *isn't* blocking, that's when the BodyHandler causes the exception to be thrown

[23:25:02] <pikajude> so making it more async would be even less helpful

[23:25:58] <D-Spair> I think there is a misunderstanding here, and without seeing your code, I can't really dig much further… Could you post an example as a Gist?

[23:26:27] <pikajude> no, thanks though

[23:26:32] <pikajude> like i said i already fixed it

[23:26:39] <D-Spair> K… Sorry I couldn't be of more help…

[23:26:42] <pikajude> ok

[23:27:15] <D-Spair> BTW, I have an example of using an AuthHandler in one of my Vert.x workshops on GitHub: https://github.com/infosec812/vertx-by-example/

[23:28:00] <D-Spair> https://github.com/infosec812/vertx-by-example/#exercise-14

[23:29:03] <D-Spair> Hmmm… Just realized that will need to be updated for Vert.x 3.4.0 soon.