Java grpc FutureStub threads question

[cr2...@gmail.com]

If as a library you're executing grpc future calls on behave on an application is there an issue just using the grpc callback threads? Would there be any need to *transfer* this back to an application provided thread to return the grpc thread back to it's pool?  As a library there's really no control over what the application may do or how long it will use that thread.

Thanks.

[Carl Mastrangelo]

By executing, you mean you are calling methods on the Future Stub?  If so, the completion of the future, and other callbacks, are executed on the executor provided to the channel when it was created (you can also fork the stub with your own executor).  gRPC will always complete the future on executor passed in, as there may be requirements (like the presence of Thread Locals, etc.) on that executor.  If you are worried about the app taking too long on one of the threads *you* provided to gRPC, you can always ask the application to provide you with an executor.  If this is not possible, an you don't particularly care about threading overhead, you can use a cached threadpool which will bring new threads into existence if the app is blocking for too long.  (Cached is also the default for gRPC itself, for the same reason). 

[cr2...@gmail.com]

Thanks Carl for the quick response.  I think this is what I expected but wanted to make sure. The main take away for now for me is that if an application *hangs* on the callback threads for sometime it won't cause any other grpc requests to block.