PubSub: subscriber.stopAsync().awaitTerminated() does not destroy respective threads #22
Labels
api: pubsub
Issues related to the googleapis/java-pubsub API.
priority: p2
Moderately-important priority. Fix may not be included in next release.
🚨
This issue needs some love.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Environment details
OS type and version: macOS 10.14.5 / Debian 4.9.168-1 (App Engine Flex)
Java version: Oracle 1.8.0_181 / openjdk version "1.8.0_212"
google-cloud-java version: 1.75.0
Steps to reproduce
Code example
Expected results
The number of active threads before calling startAsync() and after calling stopAsync() shall be equal.
Actual results
When not explicitly providing executor providers, calling startAsync() created five threads and calling stopAsync() does not stop any of them.
When providing Executors.newSingleThreadScheduledExecutor() as executorProvider and systemExecutorProvider and explicitly calling shutdown() on the executor, the result is "better" in a way that the number of threads grow much slower, but it still grows. Further, if three or more such subscribers with a custom executor provider are started and stopped, "ManagedChannel allocation site ("was not shutdown properly") exceptions appear, which suggests that the underlying gRPC state is not being cleaned up properly upon stopAsync().
Stack trace
PubSub documentation used
Related issues
java.lang.RuntimeException: ManagedChannel allocation site
when a new publisher is created google-cloud-java#3648The text was updated successfully, but these errors were encountered: