Deadline exceeded error in dgraph4j

Users Dgraph
3

I tried reproducing this, didn’t happen for me.

This expectation is not correct, as explained in this issue in grpc-java: How does deadline work? · Issue #1495 · grpc/grpc-java · GitHub. It is a deadline and not a timeout, so it is a fixed point in time when the requests will start erroring out.
The second post in the above issue explains how to use deadlines to behave as timeouts. But, that is not feasible with the Java Client as a DgraphClient object takes in a stub during construction, and so the stub that an instance of the client is using can’t be modified after that. That is the reason, the approach of ClientInterceptor mentioned in the docs is the suggested way to handle per request timeouts with the Java Client.

Now, the reason this didn’t work is because of this line:

stub.withInterceptors(timeoutInterceptor);

returns a new stub, it doesn’t change the stub on which it is called and for constructing the DgraphClient we are using the old stub.
Our docs need to be corrected here with this:

stub = stub.withInterceptors(timeoutInterceptor);
DgraphClient dgraphClient = new DgraphClient(stub);

I have tested the per-request timeout as suggested in the dgraph4j README after the correction and it works perfectly fine.

A point to note is that the Alter operation does take at least 2secs, if not run in background. So, it may be a good idea to configure different timeouts based on the service method being called, like this:

ClientInterceptor timeoutInterceptor = new ClientInterceptor(){
      @Override
      public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
          MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {
        if ("Alter".equals(method.getBareMethodName())) {
          return next.newCall(method, callOptions.withDeadlineAfter(2500, TimeUnit.MILLISECONDS));
        }
        return next.newCall(method, callOptions.withDeadlineAfter(500, TimeUnit.MILLISECONDS));
      }
    };

Some useful threads:

1 Like