Blocking request to localhost

[Lais Andrade]

Hello,

I was wondering if there is a way to make blocking requests to current http server in vertx blocking handler. For example:

Vertx vertx = Vertx.vertx();
HttpServer server = vertx.createHttpServer();
Router router = Router.router(vertx);

router.route("/1").blockingHandler(context -> {
   String result = HttpRequest.get("http://localhost:8080/2").send().body();
   context.response().end(result);
}, false);

router.route("/2").blockingHandler(context -> {
   String result = HttpRequest.get("http://localhost:8080/3").send().body();
   context.response().end(result);
}, false);

router.route("/3").handler(context -> {
   context.response().end("3");
});

System.out.println("READY!");
server.requestHandler(router::accept);
server.listen(8080);

This works if we make less concurrent requests than the worker pool size, because once we hit the worker pool limit at the first level, the nested request will not be able to get a free worker thread to run the nested request. Under siege, this server would be unavailable most of the time. I know that using vertx async http client this would work nicely. I was wondering if we need to force our server users to make requests to localhost using async http clients, even if their code runs inside a blocking handler, or if there is a way to facilitate this kind of blocking requests with vertx.

Thanks!

[Jez P]

Do you mean that you want to prevent people who are writing code for your application from using blocking http clients? This doesnt feel like a run time concern to me, but something that should be done on submission of that code. I'm sure there are Maven plugins and static analysis tools that would help but you probably need a code review process, given that there are a range of http clients that could be used. You could always offer a standard server API for people writing your server code which includes API calls to make http requests. But no, I don't think there's any run time approach to preventing this. And no bulletproof process which will work on code submission, only best efforts.

[Lais Andrade]

Thank you for your reply, Jez!

I wanted to know if there is another way of avoiding this kind of lock of resources from worker thread pool, other than just avoiding these blocking requests to localhost.

Is this the expected behavior for the server, in this scenario? Or am I missing something?

Thanks again!

[Jez P]

There is no other way. The worker pool is there so that if you must do some blocking i/o then you can, but it's highly recommended that as far as possible you avoid doing so. If you saturate the worker pool with blocking requests, they will be queued until a thread is free. You can operate a larger worker pool but that's about all you can do.

There's no way to make blocking code become non-blocking, all you can do is take it off the event loop thread and put it on a worker thread using executeBlocking or a worker verticle (or use a blocking handler). If you don't want the negatives of using blocking code, use a non-blocking API such as the vert.x http client (which would be entirely appropriate in your scenario).

May I turn your question around slightly: what is your requirement to make blocking requests to localhost (and therefore enforce use of blockingHandler)?

[Mumuney Abdlquadri]

Hello Lais,

If all that is in your route handlers is HttpRequest.get("http://localhost:8080/2").send().body();

I will advice you use the in-built vertx HTTPClient. http://vertx.io/docs/vertx-core/java/#_writing_http_servers_and_clients

You can then eliminate the blocking handlers and Worker Verticles

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6e1b0fed-e188-4aff-8c62-7ec9a85602b4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Lais Andrade]

Ok, I'll see what I can to to avoid such requests then. Thanks!

On Tuesday, September 27, 2016 at 12:53:38 PM UTC-3, Mumuney Abdlquadri wrote:

Hello Lais,

If all that is in your route handlers is HttpRequest.get("http://localhost:8080/2").send().body();

I will advice you use the in-built vertx HTTPClient. http://vertx.io/docs/vertx-core/java/#_writing_http_servers_and_clients

You can then eliminate the blocking handlers and Worker Verticles

On Mon, Sep 26, 2016 at 10:03 PM, Jez P <mr.n...@gmail.com> wrote:

There is no other way. The worker pool is there so that if you must do some blocking i/o then you can, but it's highly recommended that as far as possible you avoid doing so. If you saturate the worker pool with blocking requests, they will be queued until a thread is free. You can operate a larger worker pool but that's about all you can do.

There's no way to make blocking code become non-blocking, all you can do is take it off the event loop thread and put it on a worker thread using executeBlocking or a worker verticle (or use a blocking handler). If you don't want the negatives of using blocking code, use a non-blocking API such as the vert.x http client (which would be entirely appropriate in your scenario).

May I turn your question around slightly: what is your requirement to make blocking requests to localhost (and therefore enforce use of blockingHandler)?

On Monday, September 26, 2016 at 6:43:21 PM UTC+1, Lais Andrade wrote:

Thank you for your reply, Jez!

I wanted to know if there is another way of avoiding this kind of lock of resources from worker thread pool, other than just avoiding these blocking requests to localhost.

Is this the expected behavior for the server, in this scenario? Or am I missing something?

Thanks again!

On Saturday, September 24, 2016 at 3:21:01 AM UTC-3, Jez P wrote:

Do you mean that you want to prevent people who are writing code for your application from using blocking http clients? This doesnt feel like a run time concern to me, but something that should be done on submission of that code. I'm sure there are Maven plugins and static analysis tools that would help but you probably need a code review process, given that there are a range of http clients that could be used. You could always offer a standard server API for people writing your server code which includes API calls to make http requests. But no, I don't think there's any run time approach to preventing this. And no bulletproof process which will work on code submission, only best efforts.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.