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. On Wed, Aug 7, 2019 at 11:12 AM 'Kun Zhang' via grpc.io < [email protected]> wrote: > 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()? > > On Sunday, August 4, 2019 at 2:47:36 PM UTC-7, Derek Perez wrote: >> >> 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! >> >> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/c524128f-6f26-43ee-bb32-8ac5a07e1bb8%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/c524128f-6f26-43ee-bb32-8ac5a07e1bb8%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAD7-yfvBgTmYqhLUe3JMP22Fs65%3DBU8D%3DDFfyVdncBNF4QgkYg%40mail.gmail.com.
