It seems that CallOptions.withDeadlineAfter does not provide a fully functional timeout

[LeeYeeze]

CallOptions.withDeadlineAfter works when client and server are connected or can be connected but the server can not respond in time. When it comes to network partition, a CallOptions.blockingUnaryCall will wait about 30s to throw an exception despite the deadline.

I can walk around this by giving timeout parameters to the future.get() inside CallOptions.getUnchecked(Future future) like this

private static <V> V getUnchecked(Future<V> future) {
        try {
          return future.get(2, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
          throw Status.CANCELLED.withCause(e).asRuntimeException();
        } catch (ExecutionException e) {
          throw Status.fromThrowable(e).asRuntimeException();
        } catch (TimeoutException e) {
          throw Status.fromThrowable(e).asRuntimeException();
        }

But I believe there should be a better way @ejona86

[ejona86]

What timeout were you passing to deadlineAfter? What transport where you using (okhttp vs netty)? When the call ended up throwing an exception, what was the status?

We cancel the Call as soon as the deadline expires, so I'm not really understanding what behavior you're seeing.

Your code snippet seems like it wouldn't allow any RPC to take longer than 2 seconds.

[LeeYeeze]

Sorry @ejona86 , this is my test case, netty is used and timeout is 5s. The test case expires after around 30s every time.

public void testTimeout() {
        // inaccessible remote server caused by network partition or no rpc server listening on the port.
    ManagedChannel grpcChannel = NettyChannelBuilder.forAddress("110.75.247.90", 60009)
            .usePlaintext(true)
            .build();

    QueryServiceInterfaceBlockingStub blockingStub = QueryServiceInterfaceGrpc.newBlockingStub(grpcChannel).withDeadlineAfter(5, TimeUnit.SECONDS);
    blockingStub.query(QueryRequest.newBuilder().setQueryString("").build());
    System.out.println(System.currentTimeMillis());



}

[ejona86]

@LeeYeeze, thanks. I think I know what is going on. This is a bug with the netty transport, only during connecting.

If Netty's not connected yet, then sendCancel() queues a message in ProtocolNegotiators.AbstractBufferingHandler, thus the cancellation doesn't occur.

This is going to be a bit interesting to fix.

[ejona86]

This may have been fixed by #1494, because now cancel() will be handled by DelayedStream.