Why this code blocks?

[Igor Spasić]

It's handler that calls other handler.

public void blocking() {
   vertx = Vertx.vertx();
   HttpServer server = vertx.createHttpServer();
   Router router = Router.router(vertx);

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

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

   router.route("/3").handler(context -> {
      System.out.println(">> 1");
      context.response().end("End.");
   });

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

why this blocks:

curl localhost:8080/1

I put `true` as I was expecting it is a different context, as it is. So why blocking??

[Igor Spasić]

Aha, its because I have 1 server - aka context, right?

[ad...@cs.miami.edu]

What HttpRequest client are you using here?

 HttpRequest.get("http://localhost:8080/2").send().body();

This might be a silly question, but are you using the Vert.x http client or a client from another library?

To me, vert.x client requests look more like the following, which leads me to suspect you are  using a different library, as you do not seem to pass a handler, but using a blocking call?
:

HttpClient client = vertx.createHttpClient(); // Send a GET request client.getNow("/some-uri", response -> { System.out.println("Received response with status code " + response.statusCode()); });

-Adam

[Igor Spasić]

You are right, its blocking, and I am aware of that.

I just forgot that event context is the same for handling both requests. Btw, this is a common mistake people are facing: to think about threads and not synchronous events.

[ad...@cs.miami.edu]

Hi,

I am not sure what you mean by this statement: "Btw, this is a common mistake people are facing: to think about threads and not synchronous events."  Is this a problem you are having with understanding vert.x or your team?  It is not really clear to me what that statement means.  But here are a few thoughts anyways:

a) Try to use built in vert.x IO functions (http client, file io, TCP, Mongo, myslq client, etc) when it is available.  The issue with your code had less to do with having 1 server, and more to do with the fact that you mixed a non-vertx http client within vertx..

b) Given the above, you "can" mix in non-vertx IO with vertx, but you have to do so with some caution and awareness of what is going on.  Either wrap it in blocking call (if it is a blocking IO library).  Or, if it is another async library you have to eventually get back on to the event loop (probably using runOnContext).

That being said, your issue would be solved by just using the vertx httpclient.

-Adam

[Igor Spasić]

It can be solve also using `false` argument.

[ad...@cs.miami.edu]

You are right, but why not just use vertx httpclient and forget about the blocking handlers.   One great thing about vert.x is that it provides out-of-the-box non blocking http clients, which work great in connection with the vertx http server - nothing will block.

-Adam

[Igor Spasić]

Sure but its not me :)

We have - sort of - our users who write their code. Therefore, I can not force them what to use. I personally like async http client: https://github.com/AsyncHttpClient/async-http-client :)

thanx!

[javadevmtl]

I think for this particular case you probably should make them use vertx HTTP client. It will make life easier. You can use any 3rd party async client but then you will also have to make sure you always execute in same vertx context. It's just easier to tell your coder to use vertx HttpClient. Always do the vertx way as first as much as possible.

It's like saying here is a Ferari, it goes 200/mph and then your "user" decides to put square tires on it lol

[Mumuney Abdlquadri]

The subject reads Why this code blocks?

Adam says: :

"This might be a silly question, but are you using the Vert.x http client or a client from another library?

To me, vert.x client requests look more like the following, which leads me to suspect you are  using a different library, as you do not seem to pass a handler, but using a blocking call?"

You answered :

"You are right, its blocking, and I am aware of that."

So great you answered your own question.

--
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/b720a97f-9e1b-4516-9c43-afa90178be75%40googlegroups.com.

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

[ad...@cs.miami.edu]

Are your "users" really in the wild coders, or just other members in the same org, or project? Insisting on vertx http clients does not seem unreasonable. If it is unreadonable, perhaps a more tradition server(tomcat) might be a good fit.