Differences

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

Link to this comparison view

irc:1484780400 [2017/05/27 13:44] (current)
Line 1: Line 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.