Add request muxer remove jnats#10
Closed
skunkworker wants to merge 70 commits into
Closed
Conversation
The MRI client is working great for both jruby and mri
skunkworker
changed the title
film42
reviewed
Jun 3, 2026
elbowdonkey
reviewed
Jun 8, 2026
|
|
||
| # If time has run out, we must raise a timeout error. This is the | ||
| # definitive exit condition for the loop. | ||
| raise ::NATS::Timeout if timeout && remaining <= 0 |
There was a problem hiding this comment.
We might want to do something like this in the server loop too, for similar reasons
elbowdonkey
reviewed
Jun 8, 2026
| @pending_queue << existing_pending_queue.pop | ||
| end | ||
|
|
||
| # how to close this older queue without it blocking!? |
There was a problem hiding this comment.
probably don't need this, and the following commented line, anymore
elbowdonkey
reviewed
Jun 8, 2026
| def new_request | ||
| token = ::SecureRandom.uuid # nats.new_inbox with nuid is not threadsafe. | ||
|
|
||
| @resp_sub.synchronize do |
There was a problem hiding this comment.
If start returns nil (because it can return early with nil in at least two places), @resp_sub could be nil. And if @resp_sub is nil, we'll throw a NoMethodError here. We probably don't want that.
skunkworker
added a commit
to skunkworker/protobuf-nats
that referenced
this pull request
Jun 24, 2026
- Thread pool (mxenabled#3): wait_for_termination now prunes under the mutex, uses a monotonic deadline, and returns true (drained) / false (timed out) instead of always-nil. Added replenish (guarded against shutdown) so a worker killed by a non-StandardError is respawned; the server calls it each 1s tick. - Shutdown drain vs long handlers (mxenabled#4): the drain timeout now tracks handler_overdue_ms (+grace, configurable via PB_NATS_SERVER_SHUTDOWN_DRAIN_TIMEOUT) so a legitimate ~60s handler isn't killed mid-flight; logs/instruments the count of abandoned in-flight handlers on a hard timeout. - Async error callbacks (mxenabled#10): notify_error_callbacks_async posts to a bounded single-thread executor; the nats on_error hooks (client + server), which run on nats-pure's shared read/flush thread, now use it so a slow callback can't stall message processing for every subject. notify_error_callbacks stays synchronous. New thread_pool_spec; server/nats specs extended. Full suite 190 examples / 0 failures. 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
3 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.
Add request muxer similar to Golang's pattern.
Removed JNats.
nats-puregem is fast enough and similar for CRuby and JRuby.Thread count does not seem to increase with the increased subscriptions.
EDIT:
June 7th
Protobuf::Nats.client_nats_connection.new_inboxis not thread safe, wrapped this in amutex.sychronizeblock.breakto benextwhen encountering unexpected messages on the client. This allows for unexpected messages to be quickly moved-on from, rather than breaking out of the outerloop doloop.loggerinstance variable for a few classes for better logging.SuperSubscriptionManangerblock, this passes in the subject now, so when the thread is full we can now report the subject of the message that pushed it over the edge. (For the future, we could allow for per-subject different thread_pools)