hubcio commented on code in PR #3269:
URL: https://github.com/apache/iggy/pull/3269#discussion_r3263418620


##########
core/message_bus/src/installer/replica.rs:
##########
@@ -266,6 +267,12 @@ pub fn install_replica_conn<C: TransportConn>(
     ) {
         Ok(token) => {
             install_token.set(Some(token));
+            // Stamp this shard as the owner so every shard's
+            // `send_to_replica` slow path can route to us immediately. The
+            // matching CAS-clear runs from
+            // `IggyMessageBus::notify_connection_lost` on either of the
+            // post-loop guards firing.
+            bus.mark_replica_owned(peer_id);

Review Comment:
   yes, that's the invariant. ordering on the target shard is: 
`replicas().insert(...)` succeeds (registry is the single source of truth) -> 
`mark_replica_owned(peer_id)` stamps the owner table -> only then does the 
dispatch loop drain `rx` and accept inbound VSR. any peer sending VSR to 
`peer_id` before insert completes is by definition pre-handshake, so 
`OWNER_NONE` -> drop is correct and observable via 
`frame_drops_total{reason="owner_none"}`. CAS-clear on disconnect is the 
symmetric half.
   
   btw, `replica` is aimed to be used only in context of cluster; `shard` 
should be used only in context of single iggy-server



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to