Conversation
The MRI client is working great for both jruby and mri
goutkannan
approved these changes
Jan 6, 2023
Contributor
Author
|
Released as v0.12.0.pre0 for beta testing. |
Closed
skunkworker
added a commit
to skunkworker/protobuf-nats
that referenced
this pull request
Jun 23, 2026
Server-side follow-up to the muxer work (same nats-pure-era weak spots), with a benchmark proving the wins. #1 Fan out request intake (super_subscription_manager.rb) - The shared intake queue was drained by ONE thread that also published every ACK/NACK, so on JRuby intake was pinned to a core and one slow publish (e.g. nats-pure's buffer during a reconnect) head-of-line blocked every subject. - Drain with PB_NATS_SERVER_SUBSCRIPTION_HANDLERS threads (default processor_count on JRuby, 1 on CRuby), each with a per-thread self-healing backoff counter (a shared one would lose updates, like the muxer bug). - N-poison-pill shutdown; guard @subscriptions with a mutex. - NATS queue-group semantics and subscription counts are unchanged: each request is still delivered to exactly one consumer (SizedQueue#pop is atomic). - Bench: ~8.5x intake throughput; head-of-line stall ~505ms -> ~0.4ms (8 handlers). mxenabled#2 Handler observability, long ops first-class (server.rb) - Handlers are NEVER aborted; long-running operations (>= a minute) are allowed. - Track in-flight handlers (Concurrent::Map, monotonic start times) and emit: inflight_count, inflight_oldest_age_ms, overdue_handler_count, handler_overdue, pending_intake_queue_size, slow_handler (opt-in), thread_pool_saturated. - "overdue" is keyed to the client's response_timeout (PB_NATS_SERVER_HANDLER_ OVERDUE_MS, default 65s) so normal long ops aren't flagged. - Switch server duration metrics to a monotonic clock. Adds bench/server_intake_bench.rb and negative tests for both (head-of-line non-blocking, N-thread shutdown, long-op-allowed/not-aborted/not-flagged, slow/overdue thresholds, saturation). Full suite: 180 examples, 0 failures. Docs updated (README env vars + How it works, bench/bench.md, CHANGELOG). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.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
2 participants
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.
This adds a single subscription response router. This means all client RPC requests will share one single subscription. This works by subscribing to
<base-uuid>.*. Every time we send an RPC request, we store a new random<request-uuid>in a map, and set the reply inbox as<base-uuid>.<request-uuid>. Now, a single thread can pull messages from the wildcard subscription and signal to other waiting threads that their message is ready to be consumed.There is a bit more plumbing required to make this work, but if this work successfully and fast on both jruby and MRI, we can remove our jruby specific jnats client and the custom subscription pool stuff that we added a few years back. That would be a huge win.
Old jruby client single threaded test:
New muxed client on jruby (not using jnats):
I'm not entirely sure where the magical speedup is coming from at this point. I guess it's good to know that things appear to be working well on jruby without jnats.
MRI:
Old version:
New version:
New version is reporting a little slower, but I don't think it's a substantial impact. I guess I'm more confused by the bench results than anything.
Few other things: