Blocking calls for gRPC and HTTP even though using Reactor

Expected Behavior

Implementations of DaprClient API being non-blocking.

Actual Behavior

DaprClient API is reactive with Reactor. However, its implementations (gPRC and HTTP/1.x) at the moment are blocking, which defeats the purpose of using Reactive API. gRPC:

return Mono.fromCallable(wrap(context, () -> {
        ListenableFuture<DaprProtos.GetStateResponse> futureResponse = client.getState(envelope);
        return buildStateKeyValue(get(futureResponse), key, options, type);
      })).map(s -> new Response<>(context, s));

  private static <V> V get(ListenableFuture<V> future) {
    try {
      return future.get();
    } catch (Exception e) {
      DaprException.wrap(e);
    }

    return null;
  }

HTTP/1.1:

  public Mono<Response> invokeApi(
          String method,
          String[] pathSegments,
          Map<String, String> urlParameters,
          byte[] content,
          Map<String, String> headers,
          Context context) {
    return Mono.fromCallable(() -> doInvokeApi(method, pathSegments, urlParameters, content, headers, context));
  }

Note Mono.fromCallable only adapts the API to reactive. It still blocks a thread, be it the calling thread or the thread the Mono is subscribed on.

Steps to Reproduce the Problem

Release Note

RELEASE NOTE: FIXED implementations of DaprClient API were blocking for gRPC and HTTP.

[xiazuojie]

@xiazuojie Do you have a proposal to fix this? Since Java does not have async/await like .Net, I wonder how the Java community solves this.

Async is natively supported by gRPC java. HTTP/1.x is much more complicated. I’ll PR for gRPC.

[artursouza]

Thanks, @xiazuojie.

We only need the fix for HTTP now. GRPC is fixed.

On a side note, HTTP actually might become more relevant soon. As we are discussing if the invoke API should only be used over HTTP since gRPC to HTTP invocation cannot get the response to client easily translated due to core differences between the protocols.