Skip to content

Blocking calls for gRPC and HTTP even though using Reactor #434

Description

@xiazuojie

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.

Activity

  1. artursouza commented on Jan 5, 2021

    @artursouza
    Contributor

    @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.

  2. xiazuojie commented on Jan 6, 2021

    @xiazuojie
    ContributorAuthor

    @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.

  3. artursouza commented on Jan 6, 2021

    @artursouza
    Contributor

    HTTP is a lower priority since we use GRPC by default in the SDK. So, a PR for gRPC looks good to me. Thanks, very much.

  4. artursouza commented on Jan 6, 2021

    @artursouza
    Contributor

    This example might help with the HTTP client we have today (okHttp): https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/AsynchronousGet.java

    It is now a matter of how it can be integrated into Reactor's mono.

  5. changed the title [-]Blocking calls even though using Reactor[/-] [+]Blocking calls for gRPC and HTTP even though using Reactor[/+] on Jan 6, 2021
  6. artursouza commented on Jan 12, 2021

    @artursouza
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions