Merge pull request #270845 from spelluru/sbusissues0401

Service Bus doc issues

Author: prmerger-automator[bot]

articles/service-bus-messaging/message-deferral.md

@@ -9,21 +9,22 @@ ms.date: 06/08/2023
 When a queue or subscription client receives a message that it's willing to process, but the processing isn't currently possible because of special circumstances, it has the option of "deferring" retrieval of the message to a later point. The message remains in the queue or subscription, but it's set aside.
 
 > [!NOTE]
-> Deferred messages won't be automatically moved to the dead-letter queue [after they expire](./service-bus-dead-letter-queues.md#time-to-live). This behavior is by design.
+> Deferred messages aren't expired and automatically moved to a dead-letter queue until a client app attempts to receive them using an API and the sequence number. This behavior is by design. When a client tries to retrieve a deferred message, it's checked for [expired condition](service-bus-dead-letter-queues.md#time-to-live) and moved to a dead-letter queue if it's already expired. An expired message is moved to a deadletter subqueue only when the dead-letter feature is enabled for the entity (queue or subscription).  
 
 ## Sample scenarios
-Deferral is a feature created specifically for workflow processing scenarios. Workflow frameworks may require certain operations to be processed in a particular order. They may have to postpone processing of some received messages until prescribed prior work that's informed by other messages has been completed.
+Deferral is a feature created specifically for workflow processing scenarios. Workflow frameworks might require certain operations to be processed in a particular order. They might have to postpone processing of some received messages until prescribed prior work that's informed by other messages has been completed.
 
-A simple illustrative example is an order processing sequence in which a payment notification from an external payment provider appears in a system before the matching purchase order has been propagated from the store front to the fulfillment system. In that case, the fulfillment system might defer processing the payment notification until there's an order with which to associate it. In rendezvous scenarios, where messages from different sources drive a workflow forward, the real-time execution order may indeed be correct, but the messages reflecting the outcomes may arrive out of order.
+A simple illustrative example is an order processing sequence in which a payment notification from an external payment provider appears in a system before the matching purchase order has been propagated from the store front to the fulfillment system. In that case, the fulfillment system might defer processing the payment notification until there's an order with which to associate it. In rendezvous scenarios, where messages from different sources drive a workflow forward, the real-time execution order might indeed be correct, but the messages reflecting the outcomes might arrive out of order.
 
 Ultimately, deferral aids in reordering messages from the arrival order into an order in which they can be processed, while leaving those messages safely in the message store for which processing needs to be postponed.
 
 If a message can't be processed because a particular resource for handling that message is temporarily unavailable but message processing shouldn't be summarily suspended, a way to put that message on the side for a few minutes is to remember the sequence number in a [scheduled message](message-sequencing.md) to be posted in a few minutes, and re-retrieve the deferred message when the scheduled message arrives. If a message handler depends on a database for all operations and that database is temporarily unavailable, it shouldn't use deferral, but rather suspend receiving messages altogether until the database is available again. 
 
 ## Retrieving deferred messages
-Deferred messages remain in the main queue along with all other active messages (unlike dead-letter messages that live in a subqueue), but they can no longer be received using the regular receive operations. Deferred messages can be discovered via [message browsing](message-browsing.md) if an application loses track of them.
+Deferred messages remain in the main queue along with all other active messages (unlike dead-letter messages that live in a subqueue), but they can no longer be received using the regular receive operations. Deferred messages can be discovered via [message browsing or peeking](message-browsing.md) if an application loses track of them.
+
+To retrieve a deferred message, its owner is responsible for remembering the **sequence number** as it defers it. Any receiver that knows the sequence number of a deferred message can later receive the message by using receive methods that take the sequence number as a parameter. For more information about sequence numbers, see [Message sequencing and timestamps](message-sequencing.md).
 
-To retrieve a deferred message, its owner is responsible for remembering the sequence number as it defers it. Any receiver that knows the sequence number of a deferred message can later receive the message by using receive methods that take the sequence number as a parameter. For more information about sequence numbers, see [Message sequencing and timestamps](message-sequencing.md).
 
 ## Next steps
 Try the samples in the language of your choice to explore Azure Service Bus features. 

articles/service-bus-messaging/message-transfers-locks-settlement.md

@@ -34,10 +34,10 @@ If the application produces bursts of messages, illustrated here with a plain lo
 With an assumed 70-millisecond Transmission Control Protocol (TCP) roundtrip latency distance from an on-premises site to Service Bus and giving just 10 ms for Service Bus to accept and store each message, the following loop takes up at least 8 seconds, not counting payload transfer time or potential route congestion effects:
 
 ```csharp
-for (int i = 0; i < 100; i++)
+for (int i = 0; i < 10; i++)
 {
-  // creating the message omitted for brevity
-  await client.SendAsync(…);
+    // creating the message omitted for brevity
+    await sender.SendMessageAsync(message);
 }
 ```
 
@@ -47,9 +47,9 @@ With the same assumptions as for the prior loop, the total overlapped execution
 
 ```csharp
 var tasks = new List<Task>();
-for (int i = 0; i < 100; i++)
+for (int i = 0; i < 10; i++)
 {
-  tasks.Add(client.SendAsync(…));
+    tasks.Add(sender.SendMessageAsync(message));
 }
 await Task.WhenAll(tasks);
 ```
@@ -62,26 +62,25 @@ Semaphores, as shown in the following code snippet in C#, are synchronization ob
 var semaphore = new SemaphoreSlim(10);
 
 var tasks = new List<Task>();
-for (int i = 0; i < 100; i++)
+for (int i = 0; i < 10; i++)
 {
-  await semaphore.WaitAsync();
+    await semaphore.WaitAsync();
 
-  tasks.Add(client.SendAsync(…).ContinueWith((t)=>semaphore.Release()));
+    tasks.Add(sender.SendMessageAsync(message).ContinueWith((t)=>semaphore.Release()));
 }
 await Task.WhenAll(tasks);
 ```
 
 Applications should **never** initiate an asynchronous send operation in a "fire and forget" manner without retrieving the outcome of the operation. Doing so can load the internal and invisible task queue up to memory exhaustion, and prevent the application from detecting send errors:
 
 ```csharp
-for (int i = 0; i < 100; i++)
+for (int i = 0; i < 10; i++)
 {
-
-  client.SendAsync(message); // DON’T DO THIS
+    sender.SendMessageAsync(message); // DON’T DO THIS
 }
 ```
 
-With a low-level AMQP client, Service Bus also accepts "pre-settled" transfers. A pre-settled transfer is a fire-and-forget operation for which the outcome, either way, isn't reported back to the client and the message is considered settled when sent. The lack of feedback to the client also means that there's no actionable data available for diagnostics, which means that this mode doesn't qualify for help via Azure support.
+With a low-level AMQP client, Service Bus also accepts "presettled" transfers. A presettled transfer is a fire-and-forget operation for which the outcome, either way, isn't reported back to the client and the message is considered settled when sent. The lack of feedback to the client also means that there's no actionable data available for diagnostics, which means that this mode doesn't qualify for help via Azure support.
 
 ## Settling receive operations
 

articles/service-bus-messaging/topic-filters.md

@@ -13,16 +13,13 @@ All rules **without actions** are combined using an `OR` condition and result in
 
 Each rule **with an action** produces a copy of the message. This message will have a property called `RuleName` where the value is the name of the matching rule. The action can add or update properties, or delete properties from the original message to produce a message on the subscription. 
 
-Consider the following scenario:
-
-- Subscription has five rules.
-- Two rules contain actions.
-- Three rules don't contain actions.
-
-In this example, if you send one message that matches all five rules, you get three messages on the subscription. That's two messages for two rules with actions and one message for three rules without actions. 
+Consider the following scenario where a subscription has five rules: two rules with actions and the other three without actions. In this example, if you send one message that matches all five rules, you get three messages on the subscription. That's two messages for two rules with actions and one message for three rules without actions. 
 
 Each newly created topic subscription has an initial default subscription rule. If you don't explicitly specify a filter condition for the rule, the applied filter is the **true** filter that enables all messages to be selected into the subscription. The default rule has no associated annotation action.
 
+> [!NOTE]
+> This article applies to non-JMS scenarios. For JMS scenarios, use [message selectors](java-message-service-20-entities.md#message-selectors). 
+
 ## Filters
 Service Bus supports three types of filters: