True, I guess I was worrying incorrectly about pool deadlocks, but I guess that's something I can address with task timeouts.
On Wed, Aug 7, 2019, 1:33 PM 'Kun Zhang' via grpc.io < [email protected]> wrote: > 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]> 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/10ab08f9-0bd9-4807-b9f0-f8b0ba727d58%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/10ab08f9-0bd9-4807-b9f0-f8b0ba727d58%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-yftfvHo08XGJ5COOX5NYYtMs-v6LM-PHgyJ5UH66uUvxXw%40mail.gmail.com.
