GitHub user LI123456mo added a comment to the discussion: [Q/A][Java SDK
(Component)] For asynchronous calls, should I use asyncCall or virtual threads?
> Neither option is universally “better”; they represent two different
> programming models.
>
> `RpcContext.asyncCall(...)` is appropriate when the surrounding code is
> already asynchronous and you want to compose the result without occupying one
> application thread per request:
>
> ```java
> CompletableFuture<Result> future =
> RpcContext.getServiceContext()
> .asyncCall(() -> remoteService.query(req));
>
> return future.thenApply(this::transform);
> ```
>
> Ideally, keep the chain asynchronous instead of eventually calling `get()` on
> a platform thread.
>
> Virtual threads are useful when you prefer straightforward synchronous code.
> In that case, the important part is that the complete request/task is already
> running on a virtual thread. You can then call the synchronous Dubbo proxy
> directly:
>
> ```java
> Result result = remoteService.query(req);
> return transform(result);
> ```
>
> Wrapping one synchronous call in a newly created executor and immediately
> calling `get()` usually adds another scheduling boundary without providing
> useful concurrency. The caller still waits for the same RPC. A virtual-thread
> executor becomes useful for fan-out, where several independent calls run
> concurrently:
>
> ```java
> try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
> Future<A> a = executor.submit(() -> serviceA.query(req));
> Future<B> b = executor.submit(() -> serviceB.query(req));
> return combine(a.get(), b.get());
> }
> ```
>
> Therefore:
>
> * Existing asynchronous/reactive pipeline: use Dubbo's asynchronous API and
> compose the `CompletableFuture`.
> * Imperative thread-per-request application on JDK 21+: run the request on a
> virtual thread and use the normal synchronous Dubbo call.
> * Parallel fan-out from imperative code: virtual threads are a convenient
> option.
> * Do not wrap `asyncCall()` in another executor; Dubbo already performs the
> network operation asynchronously.
> * Virtual threads improve scalability/throughput for blocking code, not the
> latency of an individual RPC.
>
> Also be careful with `RpcContext`: it is request/thread context. If you
> submit the call to another thread, set any required attachments inside that
> submitted task or use the supported context-propagation mechanism; do not
> assume arbitrary `ThreadLocal` state will follow it.
>
> Finally, virtual threads should not be used as a downstream concurrency
> limit. If the remote service must receive at most N concurrent calls, use a
> `Semaphore`, bulkhead, or Dubbo-side concurrency controls. Creating cheap
> virtual threads does not provide backpressure.
>
> Oracle’s virtual-thread guidance makes the same distinction: synchronous
> blocking code benefits from virtual threads, while an already non-blocking
> `CompletableFuture` pipeline generally does not:
> https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
>
> Dubbo 3.3 also documents Project Loom support:
> https://dubbo.apache.org/en/blog/2024/09/11/apache-dubbo-3.3-released-triple-x-leads-a-new-era-of-microservices-communication/
Thank you so much for your response @rikhmaier , learned a lot here .
@polarisGitHub hope this answers?
GitHub link:
https://github.com/apache/dubbo/discussions/16379#discussioncomment-18624914
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
