Proper way to make use of ListenableFuture via Application Executor within a java service stub?

[Derek Perez]

I have a stub that needs to do some database I/O and I wanted to make use of ListenableFuture from Guava, wondering what the best approach to doing that would be?

I ran into this explanation of the overall server architecture: https://groups.google.com/d/msg/grpc-io/LrnAbWFozb0/VYCVarkWBQAJ

It seems like the application executor I pass in would be where I would want to do this work, so, does that mean that within a stub I should call this?

https://guava.dev/releases/23.0/api/docs/com/google/common/util/concurrent/MoreExecutors.html#newDirectExecutorService--

assuming that directExecutor() within a stub execution gives me the application executor, would that be correct? Also assuming its OK to block there. For more context I intend to use 

https://github.com/brettwooldridge/HikariCP and https://github.com/impossibl/pgjdbc-ng to do the DB communication at stub execution time, in case there are other gotchas to be aware of.

Thanks!

[Kun Zhang]

Sounds like you are implementing a service that does some database I/O.

Do you mean those referenced libraries provide ListenableFuture-based APIs, and you are asking about what executor to be passed to ListenableFuture.addListener()?

[Derek Perez]

Within a stub, I would execute database I/O using JDBI/JDBC/HikariCP which I believe results in blocking I/O. 

From what I understand, the ServerExecutor instance that is passed to NettyServerBuilder is where the stub itself is executed. If I do blocking I/O within that stub I assume other stubs running at that same time are blocked there once the number of threads serving stubs has been exhausted. So the more I research this, the more I am wondering if I should have a separate thread pool for I/IO, which in this case, would mean I would execute the blocking calls in a new executor service and wrap it in a ListeningExecutorService decorator, giving me LFs.

Sorry for the stream of consciousness, trying make sense of what is acceptable to do in the NettyServerBuilder executor (not the ELGs, specifically) vs the need for new executor pools for I/O. I am 95% sure that JDBC I/O is blocking by default, however, https://impossibl.github.io/pgjdbc-ng/ uses Netty NIO under the hood so maybe it isn't? All of this isn't super well documented so I am spelunking around to figure this stuff out.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c524128f-6f26-43ee-bb32-8ac5a07e1bb8%40googlegroups.com.

[Kun Zhang]

Regardless what those libraries are using under the hood, it's the API that matters to you. If the API is blocking, yes it will block in the executor. If the executor is exhausted, it would typically throw RejectedExecutionException, and gRPC would turn it into a stream error. This is usually the desired behavior, because at some point you would have to start rejecting new requests. What you need is to configure the executor size to reflect your desired "maximum concurrent operations". I don't see a value of making a separate executor, because it's essentially expanding the one your pass to the server builder, and it can be exhausted too.

To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.

[Derek Perez]

True, I guess I was worrying incorrectly about pool deadlocks, but I guess that's something I can address with task timeouts. 

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/10ab08f9-0bd9-4807-b9f0-f8b0ba727d58%40googlegroups.com.