BlockingStub returns iterator that cannot be closed

I use a blocking sub for a method that returns a stream of messages. The return type of it is Iterator<T>. It turns out I cannot make grpc client to end the request (e.g. because of client failure). There are a number of cases where an open connection may stuck in client because of that

The implementation uses io.grpc.stub.ClientCalls#blockingServerStreamingCall(io.grpc.Channel, io.grpc.MethodDescriptor<ReqT,RespT>, io.grpc.CallOptions, ReqT)

call, which in turn uses BlockingResponseStream. There is no way to reach the io.grpc.ClientCall#cancel method form the Iterator. Could be nice to wrap an Iterator or make it implement an interface in the similar way as done with ServerStreamObserver/ClientStreamObserver The other approach could be to implement AutoCloseable from Java with this iterator

There is also a comment on the Iterator implementation class

  // TODO(ejona86): determine how to allow ClientCall.cancel() in case of application error.

[mikeholler]

Does anyone have any examples for the use of CancellableContext with a blocking stub? I’m having a hard time finding a good official source after an hour of searching.

[ejona86]

@pskiwi, no, that wouldn’t work. After the cancellation you need to “drain” the Iterator; keep going until you get hasNext() == false. If you have a while (iter.hasNext()) iter.next(); after the finally, then it would work.

Draining the ThreadlessExecutor from a Context.CancellationListener scares me because of the threading involved.

It would be possible to add a close() method to the Iterator (and require you to cast), but in general we’re not wild about the blocking iterator API as it is far too hard to use properly. We think the proper fix here is to have a “real” blocking API.