prodriguezdefino commented on PR #40606: URL: https://github.com/apache/beam/pull/40606#issuecomment-6403631707
@sjvanrossum Thank you for the review. I can see the same decrease in throughput. One change causes it: `DEFAULT_MAX_MESSAGES_BEFORE_CHECK` which went from 100 to 0 (I left that out after testing if forcing eager checks would help). Because of that, `DirectStreamObserver` was calling `isReady()` for each message. I set the value back to 100. `ProcessBundleBenchmark.testLargeBundle`, 3 forks: |Branch | ops/s | | --- | --- | |master | 14,537 ± 360| |This PR, before the change | 12,627 ± 272| |This PR, after the change | 15,140 ± 182| |#40788 | 14,762 ± 247| I also tried a lock-free counter that calls `request()` in batches. The result was `15,205 ± 367`. This difference is in the noise so I left that out. JIC #40788 does not fix all of the deadlock. Data can arrive before `registerConsumer`. Then`consumerFuture.get(3, HOURS)` stops the gRPC thread. `onReady` uses the same thread, so `onReady` cannot run for any bundle. `InboundUnregisteredConsumerReproTest` shows this problem. The test fails on master and on #40788 and passes on this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
