是vertx webclient.send()方法阻止还是非阻滞

发布于 2025-01-18 02:53:26 字数 638 浏览 1 评论 0原文

我有一个 Verticle,它有一个处理程序,可以在事件循环线程中调用 Vertx 的 Webclient。实际的底层API调用是同步的还是异步的?它会阻塞我的事件循环线程吗?假设我的 API 调用需要 30 秒才能返回。

public class MyHandler implements Handler<Message<JsonObject>> {
  WebClient myClient;

  public MyHandler(WebClient myClient) { this.myClient = myClient; }

  @Override
  public void handle(Message<JsonObject> message) {
      myClient
        .get("url.com/the/path")
        .send().onSuccess(result -> { message.reply(result.bodyAsJson()); }
  }
}

我是否需要使用 Vertx.executeBlocking(p -> {/此处调用 api/}) 来包装 Webclient 调用? API调用是否阻塞?请注意,我的垂直体是常规垂直体,而不是工作垂直体。

I have a verticle which has a handler that calls Vertx's Webclient in the event loop thread. Is the actual underlying API call synchronous or asynchronous? Does it block my event loop thread? Assume my API call takes 30 seconds to return.

public class MyHandler implements Handler<Message<JsonObject>> {
  WebClient myClient;

  public MyHandler(WebClient myClient) { this.myClient = myClient; }

  @Override
  public void handle(Message<JsonObject> message) {
      myClient
        .get("url.com/the/path")
        .send().onSuccess(result -> { message.reply(result.bodyAsJson()); }
  }
}

Do I need to wrap the webclient call with Vertx.executeBlocking(p -> {/api call here/})? Is the API call blocking? Note that my verticle is a regular one not a worker verticle.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

爱你是孤单的心事 2025-01-25 02:53:26

所有i/o或可能长期运行的vert.x apis都是异步的。因此,发送呼叫将立即返回,然后将您传递给OnSuccess的回调将在收到响应后安排。其他代码将能够在请求正在待处理的30秒内以同一线程执行。

vert.x docs

除了很少的例外(即以“同步”结尾的一些文件系统操作),vert.x中的API都没有封锁调用线程。

如果可以立即提供结果,将立即返回,否则您通常会提供一个处理程序以稍后接收活动。

因为没有一个vert.x apis块线程,这意味着您只需使用少数线程就可以使用vert.x处理很多并发。

All Vert.x APIs that do I/O or could otherwise be long-running are asynchronous. So that send call will immediately return, and the callback you passed to onSuccess will be scheduled by Vert.x once the response is received. Other code will be able to execute in the same thread in the 30 seconds the request is pending.

As stated in the Vert.x docs:

With very few exceptions (i.e. some file system operations ending in 'Sync'), none of the APIs in Vert.x block the calling thread.

If a result can be provided immediately, it will be returned immediately, otherwise you will usually provide a handler to receive events some time later.

Because none of the Vert.x APIs block threads that means you can use Vert.x to handle a lot of concurrency using just a small number of threads.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文