[GitHub] [beam] damccorm opened a new issue, #21007: SDK should clean-up registered timer/data/... handles and not leak them with the BeamFnDataClient

[GitBox <gi...@apache.org>]

damccorm opened a new issue, #21007:
URL: https://github.com/apache/beam/issues/21007

   There is a slow leak where the map of callbacks isn't cleaned up on bundle failures.
   
   Imported from Jira [BEAM-12570](https://issues.apache.org/jira/browse/BEAM-12570). Original Jira may contain additional context.
   Reported by: boyuanz.


-- 
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: github-unsubscribe@beam.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [beam] lukecwik commented on issue #21007: SDK should clean-up registered timer/data/... handles and not leak them with the BeamFnDataClient

["lukecwik (via GitHub)" <gi...@apache.org>]

lukecwik commented on issue #21007:
URL: https://github.com/apache/beam/issues/21007#issuecomment-1401030701

   The migration to the BeamFnDataGrpcMultiplexer2 in https://github.com/apache/beam/pull/25104 would need to be updated to ensure that when we close the multiplexer that we mark the receiver as failed allowing us to stop leaking BeamFnDataGrpcMultiplexer2 instances instead of relying on the current flow which is the receiver throws an exception during accept() allowing the BeamFnDataClient to unregister the receiver and add the id to the list of known bad instruction ids.


-- 
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: github-unsubscribe@beam.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org