Feat long live zmq context pool - #2
Merged
Merged
Conversation
…call The with_zmq_socket decorator created a brand-new zmq.asyncio.Context() per RPC call and context.term()'d it in the finally block. Under the high-concurrency agent-loop store path this churned libzmq's signaler file descriptors and crashed the worker (signaler.cpp Bad file descriptor -> SIGABRT), and could also hang on the blocking term() (aggravated by sock.close(linger=-1)). Fix: the decorator now reuses the owner's long-lived context via a required get_context callable, and only creates/closes the DEALER socket per call. The context is created once per owner and terminated once at close(). Contexts are thread-safe and event-loop-agnostic, so a single shared context is safe across loops/threads; each socket stays per-call on one loop. - zmq_utils.with_zmq_socket: add required get_context; drop per-call Context()/term(); change sock.close(linger=-1) -> linger=0. - client.AsyncTransferQueueClient: own a shared self.zmq_context; destroy(linger=0) in close(). - simple_storage_manager: feed the base StorageManager's self.zmq_context via get_context. - base.StorageManager.close(): term() -> destroy(linger=0) so a leaked socket cannot hang shutdown. - tests: add test_zmq_shared_context.py asserting concurrent RPCs reuse one context and it is closed exactly once. Microbenchmark: ~7.6x faster socket setup/teardown (~210us saved per call). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
This reverts commit b54c4093d71348b3c82572ff18c3a35a0bb9dd2b. Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
This reverts commit a8bfbd81c68226f0c679ce3673c467866d470881. Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
- Guard zmq_context.destroy() against live threads. destroy() calls Socket.close() internally and is not thread-safe, but both TransferQueueClient.close() and StorageManager.close() joined their threads with a warn-only timeout and then destroyed anyway. Add a _can_destroy_zmq_context() veto that leaks the context with a loud warning instead, and document the load-bearing close() ordering. - Rename the I/O-thread knob to reflect its real scope: the context serves every backend's controller RPCs, not just SimpleStorage. TQ_SIMPLE_STORAGE_ZMQ_IO_THREADS -> TQ_CLIENT_ZMQ_IO_THREADS, kwarg simple_storage_zmq_io_threads -> zmq_io_threads. - Expose zmq_max_sockets / TQ_CLIENT_ZMQ_MAX_SOCKETS. Sharing one context per client means all in-flight sockets share libzmq's 1023-per-context budget, where previously each call had a private one. Opt-in, validated against the build's ZMQ_SOCKET_LIMIT. - Keep StorageManagerFactory.create backend-agnostic: forward **kwargs and let each registered manager decide, instead of hard-coding "SimpleStorage" in the factory and the client. KV managers accept zmq_context and deliberately keep their own. - Align the ownership check on an explicit `is None` test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
The socket-ceiling knob had tests only for the kwarg, never the env var
-- which is the deployment-facing path, since the kwarg needs a code
edit. Exercising it end to end surfaced two bugs:
- An empty value (TQ_CLIENT_ZMQ_MAX_SOCKETS=, the usual shell idiom for
clearing a variable) hit int('') and crashed the client instead of
falling back to libzmq's default. Treat empty as unset.
- A non-numeric value raised a bare int() error naming no variable,
which is hard to trace in a worker log. Name the variable.
Also add a regression test that drives the real StorageManagerFactory
with an independently-registered third-party manager. The existing
factory tests patch create() out, so nothing executed the **kwargs
forwarding; verified the new test fails if the old
`if manager_type == "SimpleStorage"` special-case is reintroduced,
while the rest of the suite stays green.
Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
Both were reachable and both are now covered by tests verified to fail when the fix is reverted. 1. A borrowing manager's stuck notify thread could not veto destroy(). StorageManager.close() detected the failed join but only acted on it inside `if self._owns_zmq_context`, so a manager that borrowed the client's context warned and returned silently. The client's veto checked only its own loop thread, so it went on to destroy a context whose sockets that thread might still hold -- the documented non-thread-safe Socket.close() hazard. The manager now records the outcome unconditionally and exposes can_destroy_zmq_context(); the client consults it, but only for a manager that actually shares the context, and TransferQueueClient now combines that with its own loop-thread check instead of replacing it. 2. Externally registered managers on the old (controller_info, config) contract raised TypeError, because the client passes zmq_context unconditionally. Registration is an extension mechanism, so managers are not required to update in lockstep: the factory now drops keywords a constructor cannot accept, warning with the class and parameter name so the drop is never silent. Constructors taking **kwargs, and un-introspectable ones, pass through unchanged. Also fix __del__ reaching for storage_manager_id on a half-constructed object, which raised AttributeError and masked the real constructor error -- found while reproducing issue 2. Signed-off-by: OutstanderWang <wangweiyanster@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.