[orchagent]: Add ZmqRouteServer for concurrent route updates by venkit-nexthop · Pull Request #4564 · sonic-net/sonic-swss

venkit-nexthop · 2026-05-12T00:49:17Z

What I did

Introduce a dedicated ZmqRouteServer (with ZmqRouteOrch and ZmqRouteConsumer) for RouteOrch to receive APPL_DB route updates from fpmsyncd. Non-fabric / non-dpu switches now create a ZmqRouteServer instead of the generic ZmqServer; fabric and DPU continue to use the existing ZmqServer (on DPU, route tables stay on the regular APPL_DB consumer path; only the DASH tables use ZMQ).

ZmqRouteConsumer merges incoming tuples into m_toSync from the mqPollThread ingress callback under m_toSyncMutex, and only notifies the orch main loop once a batch (gMaxBulkSize) has accumulated. To support this concurrent access, ConsumerBase::addToSync and dumpPendingTasks are made virtual so the route consumer can wrap them in a lock, while the default single-threaded base remains lock-free.

Other changes:

create_zmq_route_server() factory added in lib/orch_zmq_config.
getCfgSwitchType() moved earlier in orchagent main so the server type can be chosen by switch type.
fake_zmqserver updated to return a ZmqMessageHandler* from handleReceivedData to match the new signature.
New unit tests in tests/mock_tests/zmq_route_orch_ut.cpp.

Why I did it

The generic ZmqServer serializes all message handling on a single thread. For route-heavy workloads, dispatching route updates on a dedicated server with its own poll thread improves throughput and decouples the route ingestion path from the rest of the orchagent ZMQ channel.

How I verified it

Built sonic-swss locally (clean make_exit=0).
Added zmq_route_orch_ut.cpp covering the new consumer.

Details if related

N/A

Introduce a dedicated ZmqRouteServer (and ZmqRouteOrch/ZmqRouteConsumer) used by RouteOrch for receiving APPL_DB route updates from fpmsyncd. Non-fabric/non-dpu switches now create a ZmqRouteServer instead of the generic ZmqServer; fabric and DPU continue to use ZmqServer. ZmqRouteConsumer merges incoming tuples into m_toSync from the mqPollThread ingress callback under m_toSyncMutex, and only notifies the orch main loop once a batch (gMaxBulkSize) has accumulated. To support this concurrent access, ConsumerBase::addToSync and dumpPendingTasks are made virtual so the route consumer can wrap them in a lock, while the default single-threaded base remains lock-free. Also: - create_zmq_route_server() factory added in lib/orch_zmq_config. - getCfgSwitchType() moved earlier in orchagent main so the server type can be chosen based on switch type. - Update fake_zmqserver to return a ZmqMessageHandler* from handleReceivedData to match the new upstream signature. - Add zmq_route_orch_ut.cpp unit tests. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-05-12T00:49:25Z

/azp run

azure-pipelines · 2026-05-12T00:49:35Z

Azure Pipelines successfully started running 1 pipeline(s).

venkit-nexthop · 2026-05-12T02:34:04Z

tagging @deepak-singhal0408 @prabhataravind @prsunny @qiluo-msft @vivekrnv for viz

Also refer to the following PRs:

Per Task instrumentation:
sonic-net/sonic-utilities#4536
#4563

Update m_toSync from mqPollThread:
sonic-net/sonic-swss-common#1187
#4564

Resolve conflicts with upstream master (which independently added an interim ZmqServer-based ZmqRouteOrch/ZmqRouteConsumer in zmqorch.{h,cpp} and a get_route_perf_zmq_enabled() helper): - Adopt this PR's ZmqRouteServer-based ZmqRouteOrch; remove the now-superseded interim ZmqRouteOrch/ZmqRouteConsumer from zmqorch.{h,cpp}. - orchdaemon: get_route_perf_zmq_enabled() + dynamic_cast<ZmqRouteServer*>. - routeorch: base-init ZmqRouteOrch(db, tableNames, zmqRouteServer). Also apply the staging-map redesign: the ingress callback stages tuples in a plain map under m_toSyncMutex; execute() drains it into m_toSync and forwards to doTask; drain() no longer holds the lock. ConsumerBase addToSync/ dumpPendingTasks revert to non-virtual. Tests updated accordingly. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-07-13T13:28:47Z

/azp run

azure-pipelines · 2026-07-13T13:28:58Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-07-28T06:12:33Z

/azp run

azure-pipelines · 2026-07-28T06:12:45Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-07-28T18:34:47Z

/azp run

azure-pipelines · 2026-07-28T18:34:58Z

Azure Pipelines: Successfully started running 1 pipeline(s).

Follow-up to the staging-map redesign of ZmqRouteConsumer, addressing review feedback on the route ingress path. - Rename m_toSyncMutex to m_ingressMutex. The mutex only ever guarded m_ingress; the old name suggested it guarded m_toSync, which is what made the resync path (RouteOrch::doTask calling consumer.addToSync) look like a self-deadlock. Document the threading invariant on the member: m_toSync is owned exclusively by the orch main thread and no lock is held across doTask, so re-entrant addToSync from inside doTask is safe and the base ConsumerBase paths stay lock-free. - Add a TODO in drain() for the bounded, yieldable walk of m_toSync described in sections 7.4 and 7.5 of the route programming HLD (doc/orchagent/orchagent_route_redesign.md, sonic-net/SONiC#2328). Today doTask walks all of m_toSync in one go, which stalls ingress behind a large batch. - Remove the unused extern gZmqExecuteTimeQuantaMsecs declaration. It is a carry-over from zmqorch.h, has no definition anywhere in sonic-swss or sonic-swss-common, and is not referenced by ZmqRouteConsumer. It comes back with the time quanta change that actually uses it. - Add IngressCallbackConcurrentWithDrain: a producer thread stages 1000 routes through the mqPollThread ingress callback while the orch main thread spins execute(), so staging and draining interleave. Asserts every key is delivered exactly once (a new totalEntries counter on the recording orch distinguishes delivered-once from delivered-twice, which the key set alone cannot) and that the run does not deadlock. - Use static_cast<ConsumerBase &> instead of a C-style cast in ZmqRouteOrch::doTask(Consumer &). Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-07-29T20:39:50Z

/azp run

azure-pipelines · 2026-07-29T20:40:01Z

Azure Pipelines: Successfully started running 1 pipeline(s).

p4orch_tests failed to link with: test_main.cpp:288: undefined reference to `RouteOrch::RouteOrch( swss::DBConnector*, std::vector<std::pair<std::string, int>>&, SwitchOrch*, NeighOrch*, IntfsOrch*, VRFOrch*, FgNhgOrch*, Srv6Orch*, swss::ZmqRouteServer*)' orchagent/p4orch/tests keeps a hand-maintained shadow copy of routeorch.h in mock_routeorch.h, reusing the same SWSS_ROUTEORCH_H include guard, so whichever of the two headers a TU sees first wins. fake_routeorch.cpp includes mock_routeorch.h directly and so compiled against the stale declaration, emitting the ctor mangled with swss::ZmqServer*, while test_main.cpp pulls in the real routeorch.h transitively via aclorch.h before its own mock_routeorch.h include and so referenced the ctor mangled with swss::ZmqRouteServer*. Update the shadow declaration and the fake definition to take swss::ZmqRouteServer*, matching routeorch.h. The mock class keeps its Orch base; it already diverges from the real ZmqOrch/ZmqRouteOrch base and only the ctor signature affects linkage. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

…table tests/mock_tests failed to compile with: zmq_orch_ut.cpp:76:43: error: invalid conversion from 'swss::ZmqConsumerStateTable*' to 'swss::ZmqRouteConsumerStateTable*' ZmqRouteConsumer now takes a ZmqRouteConsumerStateTable rather than a plain ZmqConsumerStateTable, so the pre-existing ZmqOrchTest. ZmqRouteConsumerExecuteEmpty no longer builds. Construct the route variants instead: create_zmq_route_server() for the server and ZmqRouteConsumerStateTable for the consumer table. The latter takes no popBatchSize argument, it forwards DEFAULT_POP_BATCH_SIZE to ZmqConsumerStateTable, so drop the explicit 128. Behaviour of the test is unchanged: create_zmq_route_server() lazy-binds exactly as create_zmq_server() does, so the server never binds the port, and dbPersistence=false still keeps Redis and AsyncDBUpdater out of the test. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-07-30T03:32:30Z

/azp run

azure-pipelines · 2026-07-30T03:32:40Z

Azure Pipelines: Successfully started running 1 pipeline(s).

Three review comments on the staging-buffer path. - ZmqRouteConsumer::execute() held m_ingressMutex across addToSync(), so mqPollThread could not stage a new burst while the deque was being merged into m_toSync -- a SyncMap merge that is O(n log n) in the batch size, which is exactly the burst this design is meant to keep flowing. The comment above it already claimed the lock was "held only while moving tuples out of m_ingress", which was not true of the code. Hoist entries out of the lock scope, close the scope after m_ingress.clear(), and call addToSync() with the lock released. This is safe rather than merely faster: m_ingress is the only state shared with mqPollThread, m_toSync is owned exclusively by the orch main thread, ZmqRouteConsumer overrides neither addToSync nor dumpPendingTasks, and entries is a local, so nothing is shared once the lock drops. - Take tableNames by const reference in the vector<string> constructor's range-for instead of copying each std::string. addConsumer still takes its name by value, so this removes one copy of two; the sibling tableNames_with_pri constructor already spelled it this way. - Replace the manual save/restore of gMaxBulkSize in IngressCallbackFiresNotifyAtMaxBulkSize with a ScopedMaxBulkSize RAII guard, placed in the file's anonymous namespace next to waitFor(). A throw out of Select, ZmqClient or ZmqProducerStateTable between the set and the restore would otherwise leave the process-global clobbered at 1, silently changing the batching threshold for every later test in the binary. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-07-30T20:14:21Z

/azp run

azure-pipelines · 2026-07-30T20:14:32Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-08-02T00:26:58Z

/azp run

azure-pipelines · 2026-08-02T00:27:09Z

Azure Pipelines: Successfully started running 1 pipeline(s).

mssonicbld · 2026-08-04T05:35:12Z

/azp run

azure-pipelines · 2026-08-04T05:35:23Z

Azure Pipelines: Successfully started running 1 pipeline(s).

venkit-nexthop · 2026-08-04T18:42:41Z

@deepak-singhal0408 @prsunny @qiluo-msft
Could you approve this PR. I have incorporated comments from Qi as well.

deepak-singhal0408

1. What bounds the time a route sits in m_ingress?

The main loop is woken for this consumer by m_ingress.size() >= gMaxBulkSize or by mqPollThread after a burst quiesces, and hasCachedData() returns false, so Select doesn't re-arm on staged data. A stream that arrives faster than the quiesce threshold but never reaches gMaxBulkSize distinct keys hits neither condition. Is that regime characterised, or is the assumption that there is always a gap?

2. Is ZmqOrch() = default; still needed?

Its only user on master is ZmqRouteOrch : public ZmqOrch delegating : ZmqOrch(). This PR reparents to Orch, and the ten remaining subclasses all use a table-iterating constructor. Looks removable in this PR.

Related: reparenting duplicates both constructors, the DB-id gate, the legacy Consumer fallback and doTask(Consumer&) across zmqorch.cpp and zmqrouteorch.cpp. How would a future fix to ZmqOrch::addConsumer()'s fallback reach the route copy?

3. m_ingress isn't visible to any pending-task surface.

ConsumerBase::dumpPendingTasks() walks m_toSync and the retry cache, and ZmqRouteConsumer doesn't override it — so staged tuples appear in neither the SIGUSR1 dump nor the show orchagent tasks output from sonic-swss 4563 + sonic-utilities 4536. A backlog in m_ingress and an idle system look the same from outside. §7.12 covers per-Executor timing, not queue depth.

Non-blocking — raising it so it can be tracked for a later increment.

4. HLD §7.3–§7.5 predate the staging-map revision and now contradict §7.2.

SONiC 2328 cc3f5061 revised sections 4, 6.3, 7.2, 7.9, 12 and 13.1 to match this design. §7.2 now states "the poll thread never calls addToSync() and never touches m_toSync." But §7.5 still reads:

"To keep m_toSync independent and allow mqPollThread to keep updating (and coalescing) it, toBulkTask consults m_toSync in a manner that allows concurrent access."

Those describe different threading models. It matters for what happens next: under §7.4 the yield resumes by posting a notification to self, which re-enters execute() and repeats the full m_ingress → m_toSync swap, while §7.5's toBulkTask takes a bounded slice and removes what it takes. Whether m_ingress survives that increment, and whether the hand-off stays uncapped, isn't stated in either.

Worth reconciling §7.3–§7.5 with the revised §7.2 in 2328.

Close the three coverage gaps called out in review: - SameKeyBurstCoalescesInIngress: two updates to the same key inside one batched ZMQ message (ZmqProducerStateTable::set(vector) produces a single message, hence a single ingress-callback invocation), pinning that staging is last-writer-wins wholesale -- exactly one delivery carrying only the second update's fields, never a field union. totalEntries == 1 makes a transport split fail loudly instead of passing as two deliveries. - SelectWakesAfterBurstQuiesce: with gMaxBulkSize pinned high so the mid-burst threshold branch is unreachable, a single staged tuple must still wake the Select loop via mqPollThread's post-burst quiesce notify -- the common wake path at the default bulk size. - m_ingress drain completeness: the staging members move from private to protected so the tests (which compile with protected mapped to public, as they already do for m_toSync) can assert m_ingress.empty() after drains; asserts added to the ingress tests, plus a leak trap in IngressCallbackConcurrentWithDrain -- an extra execute() after convergence must not grow the delivery count. The recording orch now captures the delivered fields per key; the key set alone cannot distinguish last-writer-wins from a field union. Verified against sonic-swss-common master debs: full mock_tests suite 945/945, ZmqRoute suites 14/14. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-08-05T21:34:49Z

/azp run

azure-pipelines · 2026-08-05T21:35:01Z

Azure Pipelines: Successfully started running 1 pipeline(s).

venkit-nexthop · 2026-08-05T22:33:11Z

1. What bounds the time a route sits in m_ingress?

The main loop is woken for this consumer by m_ingress.size() >= gMaxBulkSize or by mqPollThread after a burst quiesces, and hasCachedData() returns false, so Select doesn't re-arm on staged data. A stream that arrives faster than the quiesce threshold but never reaches gMaxBulkSize distinct keys hits neither condition. Is that regime characterised, or is the assumption that there is always a gap?

You're right that there's no explicit time bound today.
The scenario you describe is possible -- a stream with no 5ms gap and fewer than gMaxBulkSize distinct keys would keep getting deferred.

Two things limit the damage. First, m_ingress coalesces by key, so the backlog doesn't grow — it holds one tuple per key, and whenever the drain does happen it programs the latest state, not stale intermediate
ones. So the failure mode is delayed convergence during a sustained flap, not wrong state or memory growth. Second, hitting it needs literally zero 5ms silences — any gap will flush it.

One proposal to avoid this in the very rare case:
Track the timestamp of the oldest staged entry and have mqPollThread fire
notifyPending() if age exceeds a cap (say 50ms) even mid-burst.
I think, this is best implemented in sonic-swss-common. I need to fix Qi's comments in sonic-swss-common anyways. I will fix it as part of that PR.

2. Is ZmqOrch() = default; still needed?

Its only user on master is ZmqRouteOrch : public ZmqOrch delegating : ZmqOrch(). This PR reparents to Orch, and the ten remaining subclasses all use a table-iterating constructor. Looks removable in this PR.

Related: reparenting duplicates both constructors, the DB-id gate, the legacy Consumer fallback and doTask(Consumer&) across zmqorch.cpp and zmqrouteorch.cpp. How would a future fix to ZmqOrch::addConsumer()'s fallback reach the route copy?

I am inclined to leave the ZmqOrch constructor default as-is. No harm there.
Regarding the duplication comment, I kept ZmqRouteOrch separate rather than deriving from ZmqOrch because addConsumer diverges further in the follow-ups (the route consumer grows yield/resume and time-quanta behavior
from HLD 7.3-7.5 that the generic path shouldn't carry).

3. m_ingress isn't visible to any pending-task surface.

ConsumerBase::dumpPendingTasks() walks m_toSync and the retry cache, and ZmqRouteConsumer doesn't override it — so staged tuples appear in neither the SIGUSR1 dump nor the show orchagent tasks output from sonic-swss 4563 + sonic-utilities 4536. A backlog in m_ingress and an idle system look the same from outside. §7.12 covers per-Executor timing, not queue depth.

Non-blocking — raising it so it can be tracked for a later increment.

Thanks. I will look at this in a subsequent PR.

4. HLD §7.3–§7.5 predate the staging-map revision and now contradict §7.2.

SONiC 2328 cc3f5061 revised sections 4, 6.3, 7.2, 7.9, 12 and 13.1 to match this design. §7.2 now states "the poll thread never calls addToSync() and never touches m_toSync." But §7.5 still reads:

"To keep m_toSync independent and allow mqPollThread to keep updating (and coalescing) it, toBulkTask consults m_toSync in a manner that allows concurrent access."

Those describe different threading models. It matters for what happens next: under §7.4 the yield resumes by posting a notification to self, which re-enters execute() and repeats the full m_ingress → m_toSync swap, while §7.5's toBulkTask takes a bounded slice and removes what it takes. Whether m_ingress survives that increment, and whether the hand-off stays uncapped, isn't stated in either.

Worth reconciling §7.3–§7.5 with the revised §7.2 in 2328.

I will fix the HLD. Thanks for pointing this out. This is left over from prior to Qi's comments.

deepak-singhal0408 · 2026-08-06T06:56:51Z

Hi @prsunny @prabhataravind, could you help review/sign-off this PR. thanks,

Copilot

Pull request overview

This PR introduces a route-specific ZMQ ingestion path in orchagent by adding ZmqRouteServer/ZmqRouteOrch/ZmqRouteConsumer, aiming to improve throughput for route-heavy workloads by decoupling route updates from the generic ZMQ server.

Changes:

Added new ZmqRouteOrch/ZmqRouteConsumer implementation and wired RouteOrch to consume from a ZmqRouteServer.
Updated orchagent startup/server selection and config helpers to support creating a ZmqRouteServer.
Added/updated mock tests and build integration (Makefile.am) for the new route ZMQ components.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
tests/mock_tests/zmq_route_orch_ut.cpp	Adds new unit tests for `ZmqRouteOrch`/`ZmqRouteConsumer` behaviors and concurrency staging.
tests/mock_tests/zmq_orch_ut.cpp	Updates existing ZMQ unit test to use `create_zmq_route_server()` and `ZmqRouteConsumerStateTable`.
tests/mock_tests/Makefile.am	Registers new route ZMQ unit test and compiles `zmqrouteorch.cpp` into mock tests.
orchagent/zmqrouteorch.h	Introduces public API for `ZmqRouteOrch` and `ZmqRouteConsumer`.
orchagent/zmqrouteorch.cpp	Implements ingress staging + drain logic and consumer creation for route tables.
orchagent/zmqorch.h	Removes the previous `ZmqRouteOrch`/`ZmqRouteConsumer` declarations from the generic ZMQ path.
orchagent/zmqorch.cpp	Removes the previous `ZmqRouteOrch`/`ZmqRouteConsumer` implementations from the generic ZMQ path.
orchagent/routeorch.h	Switches `RouteOrch` to inherit from the new `ZmqRouteOrch` and accept a route server pointer.
orchagent/routeorch.cpp	Updates `RouteOrch` ctor to construct the new `ZmqRouteOrch` base with the route server.
orchagent/p4orch/tests/mock_routeorch.h	Updates test double signature to match new `RouteOrch` ctor server type.
orchagent/p4orch/tests/Makefile.am	Ensures `zmqrouteorch.cpp` is compiled into p4orch tests.
orchagent/p4orch/tests/fake_routeorch.cpp	Updates fake `RouteOrch` ctor signature to match new server type.
orchagent/orchdaemon.cpp	Wires `RouteOrch` creation to use a `ZmqRouteServer` derived from `m_zmqServer`.
orchagent/Makefile.am	Adds `zmqrouteorch.cpp` to orchagent build sources.
orchagent/main.cpp	Moves switch-type detection earlier and selects between generic vs route ZMQ server creation.
lib/orch_zmq_config.h	Adds factory declaration `create_zmq_route_server()`.
lib/orch_zmq_config.cpp	Implements `create_zmq_route_server()` factory.

Suppressed comments (1)

orchagent/zmqrouteorch.h:55

ZmqRouteOrch declares ZmqRouteServer* without the swss:: qualifier even though other parts of the tree use swss::ZmqRouteServer (e.g. p4orch test doubles). Qualifying the type here avoids ambiguity and makes the header consistent with existing ZMQ types (swss::ZmqServer).

class ZmqRouteOrch : public Orch
{
public:
    ZmqRouteOrch(swss::DBConnector *db, const std::vector<std::string> &tableNames, ZmqRouteServer *zmqServer);
    ZmqRouteOrch(swss::DBConnector *db, const std::vector<table_name_with_pri_t> &tableNames_with_pri, ZmqRouteServer *zmqServer);

    virtual void doTask(ConsumerBase &consumer) { };
    void doTask(Consumer &consumer) override;

private:
    void addConsumer(swss::DBConnector *db, std::string tableName, int pri, ZmqRouteServer *zmqServer);
};

…e_zmq_route_server Use swss:: explicitly for ZmqRouteServer and ZmqRouteConsumerStateTable instead of relying on a header-side using-directive, matching zmqorch.h. Also make the create_zmq_route_server log line distinguishable from create_zmq_server and include the vrf. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>

mssonicbld · 2026-08-07T03:55:18Z

/azp run

azure-pipelines · 2026-08-07T03:55:29Z

Azure Pipelines: Successfully started running 1 pipeline(s).

venkit-nexthop requested a review from prsunny as a code owner May 12, 2026 00:49

venkit-nexthop mentioned this pull request May 12, 2026

Performance Regression in Orchagent due to https://github.com/sonic-net/sonic-swss/pull/3910/changes sonic-net/sonic-buildimage#27098

Open

rbikkina-nexthop reviewed May 13, 2026

View reviewed changes

Comment thread orchagent/routeorch.cpp

rbikkina-nexthop reviewed May 13, 2026

View reviewed changes

Comment thread orchagent/zmqrouteorch.cpp Outdated

rbikkina-nexthop reviewed May 13, 2026

View reviewed changes

Comment thread orchagent/zmqrouteorch.h Outdated

rbikkina-nexthop reviewed May 13, 2026

View reviewed changes

Comment thread tests/mock_tests/zmq_route_orch_ut.cpp

rbikkina-nexthop reviewed May 13, 2026

View reviewed changes

Comment thread orchagent/zmqrouteorch.cpp Outdated

deepak-singhal0408 added this to SONiC Routing Dashboard May 14, 2026

github-project-automation Bot moved this to Todo in SONiC Routing Dashboard May 14, 2026

deepak-singhal0408 assigned venkit-nexthop May 14, 2026

This was referenced Jul 10, 2026

[golden_config]: enable SWSS ZMQ on T2 and DRH topologies sonic-net/sonic-mgmt#26043

Open

Bug: fpmsyncd drops route updates (zmq send failed, EAGAIN) under route burst when swss_zmq is enabled sonic-net/sonic-buildimage#28369

Open

deepak-singhal0408 moved this from Todo to In Progress in SONiC Routing Dashboard Jul 23, 2026

Merge branch 'master' into orchagent-zmq-route-server

d4f0e5f

Merge branch 'sonic-net:master' into orchagent-zmq-route-server

1dd27dd

Merge branch 'sonic-net:master' into orchagent-zmq-route-server

e46feeb

Merge branch 'sonic-net:master' into orchagent-zmq-route-server

d6aedb4

deepak-singhal0408 reviewed Aug 5, 2026

View reviewed changes

Comment thread tests/mock_tests/zmq_route_orch_ut.cpp

deepak-singhal0408 reviewed Aug 5, 2026

View reviewed changes

venkit-nexthop mentioned this pull request Aug 6, 2026

[zmq] Fix use-after-free in deferred burst notify; bound notification deferral sonic-net/sonic-swss-common#1234

Open

deepak-singhal0408 previously approved these changes Aug 6, 2026

View reviewed changes

deepak-singhal0408 requested a review from prabhataravind August 6, 2026 06:55

prabhataravind requested a lite review from Copilot August 6, 2026 20:36

Copilot started reviewing on behalf of prabhataravind August 6, 2026 20:36 View session

Copilot AI reviewed Aug 6, 2026

View reviewed changes

Comment thread orchagent/zmqrouteorch.h

Comment thread lib/orch_zmq_config.cpp Outdated

Comment thread orchagent/routeorch.h Outdated

Comment thread orchagent/routeorch.cpp Outdated

Comment thread orchagent/orchdaemon.cpp

venkit-nexthop dismissed deepak-singhal0408’s stale review via 81d467c August 7, 2026 03:55

Uh oh!

Conversation

venkit-nexthop commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mssonicbld commented May 12, 2026

Uh oh!

azure-pipelines Bot commented May 12, 2026

Uh oh!

venkit-nexthop commented May 12, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mssonicbld commented Jul 13, 2026

Uh oh!

azure-pipelines Bot commented Jul 13, 2026

Uh oh!

mssonicbld commented Jul 28, 2026

Uh oh!

azure-pipelines Bot commented Jul 28, 2026

Uh oh!

mssonicbld commented Jul 28, 2026

Uh oh!

azure-pipelines Bot commented Jul 28, 2026

Uh oh!

mssonicbld commented Jul 29, 2026

Uh oh!

azure-pipelines Bot commented Jul 29, 2026

Uh oh!

mssonicbld commented Jul 30, 2026

Uh oh!

azure-pipelines Bot commented Jul 30, 2026

Uh oh!

mssonicbld commented Jul 30, 2026

Uh oh!

azure-pipelines Bot commented Jul 30, 2026

Uh oh!

mssonicbld commented Aug 2, 2026

Uh oh!

azure-pipelines Bot commented Aug 2, 2026

Uh oh!

mssonicbld commented Aug 4, 2026

Uh oh!

azure-pipelines Bot commented Aug 4, 2026

Uh oh!

venkit-nexthop commented Aug 4, 2026

Uh oh!

Uh oh!

deepak-singhal0408 left a comment

Choose a reason for hiding this comment

Uh oh!

mssonicbld commented Aug 5, 2026

Uh oh!

azure-pipelines Bot commented Aug 5, 2026

Uh oh!

venkit-nexthop commented Aug 5, 2026

Uh oh!

deepak-singhal0408 commented Aug 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mssonicbld commented Aug 7, 2026

Uh oh!

azure-pipelines Bot commented Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

venkit-nexthop commented May 12, 2026 •

edited

Loading