{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "slug": "dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role", "url": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/" }, "title": "Interpret Service Fabric replication-queue warnings by replica role", "summary": "Where should investigation begin when a Service Fabric replication queue is full on the primary versus a secondary?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:23:32+00:00", "modified_at": "2026-09-10T02:11:17+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 246, "potentially_affected": "Service Fabric replicas reporting PrimaryReplicationQueueStatus or SecondaryReplicationQueueStatus.", "dse_recommendation": "DSE recommends preserving the reporting replica's role before assigning a queue warning to a storage or network owner.", "primary_source": { "name": "Troubleshoot with system health reports - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

Service Fabric reports a full replication queue through System.Replicator. On a primary, the usual cause is slow acknowledgement by a secondary; on a secondary, it is usually slow application of operations. The warning clears when the queue is no longer full. The documented investigation starts with inter-node connectivity for a primary warning, but disk usage and performance on the reporting node for a secondary warning. Microsoft Learn.

\n

Applicability

\n

Use the report’s property and replica role to identify which branch applies. These are documented common causes, not a conclusive diagnosis of a particular machine. Avoid interpreting every queue warning as evidence that the reporting node’s own disk is the bottleneck.

\n

DSE recommendation

\n

DSE recommends preserving the reporting replica’s role before assigning a queue warning to a storage or network owner. For a primary report, review connectivity and then investigate slow secondary acknowledgement. For a secondary report, start with its disk observations and examine its connection back to the primary. Keep the participating replica and node identities attached to the evidence so the two perspectives are not mixed.

\n

Verification

\n

Compare the warning interval with relevant connection and disk observations during an approved investigation. Record whether the queue warning clears after the identified cause is corrected, while separately testing the application’s expected operation. If the measurements do not support the common cause, retain that mismatch and continue diagnosis rather than labeling a component failed solely from the queue property.

\n

Official references

\n

Microsoft Learn. Source retrieved September 9, 2026.

", "content_text": "Source facts\nService Fabric reports a full replication queue through System.Replicator. On a primary, the usual cause is slow acknowledgement by a secondary; on a secondary, it is usually slow application of operations. The warning clears when the queue is no longer full. The documented investigation starts with inter-node connectivity for a primary warning, but disk usage and performance on the reporting node for a secondary warning. Microsoft Learn.\nApplicability\nUse the report’s property and replica role to identify which branch applies. These are documented common causes, not a conclusive diagnosis of a particular machine. Avoid interpreting every queue warning as evidence that the reporting node’s own disk is the bottleneck.\nDSE recommendation\nDSE recommends preserving the reporting replica’s role before assigning a queue warning to a storage or network owner. For a primary report, review connectivity and then investigate slow secondary acknowledgement. For a secondary report, start with its disk observations and examine its connection back to the primary. Keep the participating replica and node identities attached to the evidence so the two perspectives are not mixed.\nVerification\nCompare the warning interval with relevant connection and disk observations during an approved investigation. Record whether the queue warning clears after the identified cause is corrected, while separately testing the application’s expected operation. If the measurements do not support the common cause, retain that mismatch and continue diagnosis rather than labeling a component failed solely from the queue property.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nService Fabric reports a full replication queue through System.Replicator. On a primary, the usual cause is slow acknowledgement by a secondary; on a secondary, it is usually slow application of operations. The warning clears when the queue is no longer full. The documented investigation starts with inter-node connectivity for a primary warning, but disk usage and performance on the reporting node for a secondary warning. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports).\n\n## Applicability\n\nUse the report’s property and replica role to identify which branch applies. These are documented common causes, not a conclusive diagnosis of a particular machine. Avoid interpreting every queue warning as evidence that the reporting node’s own disk is the bottleneck.\n\n## DSE recommendation\n\nDSE recommends preserving the reporting replica’s role before assigning a queue warning to a storage or network owner. For a primary report, review connectivity and then investigate slow secondary acknowledgement. For a secondary report, start with its disk observations and examine its connection back to the primary. Keep the participating replica and node identities attached to the evidence so the two perspectives are not mixed.\n\n## Verification\n\nCompare the warning interval with relevant connection and disk observations during an approved investigation. Record whether the queue warning clears after the identified cause is corrected, while separately testing the application’s expected operation. If the measurements do not support the common cause, retain that mismatch and continue diagnosis rather than labeling a component failed solely from the queue property.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports). Source retrieved September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "url": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Interpret Service Fabric replication-queue warnings by replica role", "item": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "url": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/", "headline": "Interpret Service Fabric replication-queue warnings by replica role", "description": "Where should investigation begin when a Service Fabric replication queue is full on the primary versus a secondary?", "abstract": "Where should investigation begin when a Service Fabric replication queue is full on the primary versus a secondary?", "articleBody": "Source facts\nService Fabric reports a full replication queue through System.Replicator. On a primary, the usual cause is slow acknowledgement by a secondary; on a secondary, it is usually slow application of operations. The warning clears when the queue is no longer full. The documented investigation starts with inter-node connectivity for a primary warning, but disk usage and performance on the reporting node for a secondary warning. Microsoft Learn.\nApplicability\nUse the report’s property and replica role to identify which branch applies. These are documented common causes, not a conclusive diagnosis of a particular machine. Avoid interpreting every queue warning as evidence that the reporting node’s own disk is the bottleneck.\nDSE recommendation\nDSE recommends preserving the reporting replica’s role before assigning a queue warning to a storage or network owner. For a primary report, review connectivity and then investigate slow secondary acknowledgement. For a secondary report, start with its disk observations and examine its connection back to the primary. Keep the participating replica and node identities attached to the evidence so the two perspectives are not mixed.\nVerification\nCompare the warning interval with relevant connection and disk observations during an approved investigation. Record whether the queue warning clears after the identified cause is corrected, while separately testing the application’s expected operation. If the measurements do not support the common cause, retain that mismatch and continue diagnosis rather than labeling a component failed solely from the queue property.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:23:32+00:00", "dateModified": "2026-09-10T02:11:17+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-504-interpret-service-fabric-replication-queue-warnings-by-replica-role/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Interpret Service Fabric replication-queue warnings by replica role" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 246, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Troubleshoot with system health reports - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-understand-and-troubleshoot-with-system-health-reports" } } ] } }