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.
On Wednesday, August 7, 2019 at 11:22:41 AM UTC-7, Derek Perez wrote: > > 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] <javascript:>> 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] <javascript:>. >> 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/10ab08f9-0bd9-4807-b9f0-f8b0ba727d58%40googlegroups.com.
