Summary
P2PStore.__init__ retries transfer-engine initialization up to 8 times, but it creates a new TransferEngine() on every attempt. If a failed engine initialization leaves sockets, ports, file descriptors, or shared-memory state behind, each retry can leak resources or keep the same conflict alive.
Why this matters
The retry loop is meant to recover from startup port conflicts. If failed TransferEngine instances hold resources until GC or process exit, retrying with a fresh object may make the failure more persistent and can leave unnecessary native resources around.
Suggested investigation
- Check the
mooncake-transfer-engine lifecycle API for an explicit close/destroy/shutdown method.
- Confirm whether a failed
initialize() call owns any resources that must be released.
- Either reuse one
TransferEngine across retries or explicitly clean up the failed instance before the next attempt.
- Add a focused test with a fake engine if a cleanup seam can be introduced without importing mooncake in CPU-only tests.
Summary
P2PStore.__init__retries transfer-engine initialization up to 8 times, but it creates a newTransferEngine()on every attempt. If a failed engine initialization leaves sockets, ports, file descriptors, or shared-memory state behind, each retry can leak resources or keep the same conflict alive.Why this matters
The retry loop is meant to recover from startup port conflicts. If failed
TransferEngineinstances hold resources until GC or process exit, retrying with a fresh object may make the failure more persistent and can leave unnecessary native resources around.Suggested investigation
mooncake-transfer-enginelifecycle API for an explicit close/destroy/shutdown method.initialize()call owns any resources that must be released.TransferEngineacross retries or explicitly clean up the failed instance before the next attempt.