You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/service-bus-messaging/message-sessions.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,6 +69,13 @@ The definition of delivery count per message in the context of sessions varies s
69
69
| Session is accepted, the messages within the session aren't completed (even if they're locked), and the session is closed | No |
70
70
| Session is accepted, messages are completed, and then the session is explicitly closed | N/A (It's the standard flow. Here, messages are removed from the session) |
71
71
72
+
## Maximum delivery count in sessions
73
+
74
+
When a message in a session is abandoned (for example, due to a processing failure), it becomes available again for the receiver until the [`MaxDeliveryCount`](service-bus-dead-letter-queues.md#maximum-delivery-count) for the queue or subscription is exceeded. The default value is 10. Once exceeded, the message is moved to the [dead-letter queue (DLQ)](service-bus-dead-letter-queues.md), and the receiver continues receiving subsequent messages from the session.
75
+
76
+
> [!IMPORTANT]
77
+
> If a dead-lettered message is later moved back to the original queue for reprocessing, the original ordering relative to other session messages is lost because the resubmitted message receives a new enqueue time and sequence number.
78
+
72
79
## Request-response pattern
73
80
The [request-reply pattern](https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html) is a well-established integration pattern that enables the sender application to send a request and provides a way for the receiver to correctly send a response back to the sender application. This pattern typically needs a short-lived queue or topic for the application to send responses to. In this scenario, sessions provide a simple alternative solution with comparable semantics.
Copy file name to clipboardExpand all lines: articles/virtual-network/virtual-network-manage-subnet.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,6 +74,14 @@ To do tasks on subnets, your account must be assigned to the [Network contributo
74
74
| Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action | Enable a service endpoint for a subnet. |
75
75
| Microsoft.Network/virtualNetworks/subnets/virtualMachines/read | Get the virtual machines in a subnet. |
76
76
77
+
> [!NOTE]
78
+
> If attempts to add, change, or delete a subnet in your virtual network fail, ensure there are no connections to other resources that may block the action:
Copy file name to clipboardExpand all lines: articles/virtual-network/virtual-network-routing-appliance-overview.md
+35Lines changed: 35 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,37 @@ Key characteristics:
37
37
- You host a routing appliance in a dedicated subnet named `VirtualNetworkApplianceSubnet`.
38
38
- A routing appliance forwards traffic in the data path.
39
39
40
+
## Common routing patterns (hub and spoke)
41
+
42
+
Most deployments use a virtual network routing appliance in a hub virtual network to provide scalable spoke-to-spoke (east-west) transit. Common patterns include:
43
+
44
+
### Pattern 1: Route Azure private address space to the appliance
45
+
46
+
Use UDRs on spoke subnets to route your Azure private address space (for example, RFC1918) to the routing appliance, while routing internet egress and on-premises prefixes to other next hops as appropriate.
47
+
48
+
This pattern is useful when:
49
+
- You want the routing appliance to carry east-west traffic, but not become the default next hop for all traffic.
50
+
- You already have an established egress design (for example, Azure Firewall or NAT Gateway) that you don’t want to change.
51
+
52
+
### Pattern 2: Default-route spokes to the appliance (simplified spoke UDRs)
53
+
54
+
Use a 0.0.0.0/0 UDR on spoke subnets with the routing appliance as the next hop, and then route on-premises and internet traffic from the hub according to your architecture.
55
+
56
+
This pattern is useful when:
57
+
- You want “cookie cutter” spoke route tables (simpler to operate at scale).
58
+
- You want to avoid maintaining many per-prefix UDR entries in spokes.
59
+
60
+
> [!IMPORTANT]
61
+
> Review the limitations section carefully before using a default route to the appliance, especially for Azure Private Link / Private Endpoint traffic.
Use RFC1918 routes to the routing appliance to handle spoke-to-spoke and private transit, and send 0.0.0.0/0 to your chosen egress solution.
66
+
67
+
This pattern is useful when:
68
+
- You want predictable east-west routing via the appliance.
69
+
- You want to keep internet egress flows pinned to your egress solution and reduce the risk of asymmetric routing through a firewall.
70
+
40
71
## Benefits
41
72
42
73
### High throughput and maximum connections
@@ -96,6 +127,10 @@ The preview is free. We'll provide advance notice before billing is enabled.
96
127
97
128
## Registration
98
129
130
+
> [!NOTE]
131
+
> Bandwidth and scaling behavior in preview are subject to change. If you need to change the configured bandwidth after deployment, you will need to redeploy the resource.
132
+
133
+
## How to request support and provide feedback
99
134
After you submit your Azure Feature Exposure Control (AFEC) registration for `Microsoft.network/AllowVirtualNetworkAppliance`, finish the preview [sign-up form](https://forms.office.com/r/kqEKRr5mpB).
0 commit comments