Merge pull request #267106 from spelluru/sbusfreshness0222

Service Bus freshness review

Author: prmerger-automator[bot]

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

@@ -2,7 +2,7 @@
 title: Azure Service Bus message sessions | Microsoft Docs
 description: This article explains how to use sessions to enable joint and ordered handling of unbounded sequences of related messages.
 ms.topic: article
-ms.date: 02/14/2023
+ms.date: 02/23/2024
 ---
 
 # Message sessions
@@ -29,15 +29,15 @@ For samples, use links in the [Next steps](#next-steps) section.
 
 ### Session features
 
-Sessions provide concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.
+Sessions provide concurrent demultiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.
 
-![A diagram showing how the Sessions feature preserves ordered delivery.][1]
+:::image type="content" source="./media/message-sessions/sessions.png" alt-text="Diagram that shows how the Sessions feature preserves an ordered delivery.":::
 
-A session receiver is created by a client accepting a session. When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's **session ID** in the queue or subscription. It will also hold exclusive locks on all messages with the **session ID** that will arrive later.
+A session receiver is created by a client accepting a session. When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's **session ID** in the queue or subscription. It holds exclusive locks on all messages with the **session ID** that arrive later.
 
 The lock is released when you call close methods on the receiver or when the lock expires. There are methods on the receiver to renew the locks as well. Instead, you can use the automatic lock renewal feature where you can specify the time duration for which you want to keep getting the lock renewed. The session lock should be treated like an exclusive lock on a file, meaning that the application should close the session as soon as it no longer needs it and/or doesn't expect any further messages.
 
-When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. With that operation, an interleaved message stream in one queue or subscription is cleanly de-multiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.
+When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. With that operation, an interleaved message stream in one queue or subscription is cleanly demultiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.
 
 The previous illustration shows three concurrent session receivers. One Session with `SessionId` = 4 has no active, owning client, which means that no messages are delivered from this specific session. A session acts in many ways like a sub queue.
 
@@ -51,7 +51,7 @@ The session state facility enables an application-defined annotation of a messag
 
 From the Service Bus perspective, the message session state is an opaque binary object that can hold data of the size of one message, which is 256 KB for Service Bus Standard, and 100 MB for Service Bus Premium. The processing state relative to a session can be held inside the session state, or the session state can point to some storage location or database record that holds such information.
 
-The methods for managing session state, SetState and GetState, can be found on the session receiver object. A session that had previously no session state returns a null reference for GetState. The previously set session state can be cleared by passing null to the SetState method on the receiver.
+The methods for managing session state, `SetState` and `GetState`, can be found on the session receiver object. A session that had previously no session state returns a null reference for `GetState`. The previously set session state can be cleared by passing null to the `SetState` method on the receiver.
 
 Session state remains as long as it isn't cleared up (returning **null**), even if all messages in a session are consumed.
 
@@ -90,7 +90,7 @@ So, the messages are processed in this order: message 2, message 3, and message
 If messages just need to be retrieved in order, you don't need to use sessions. If messages need to be processed in order, use sessions. The same session ID should be set on messages that belong together, which could be message 1, 4, and 8 in a set, and 2, 3, and 6 in another set. 
 
 ## Message expiration
-For session-enabled queues or topics' subscriptions, messages are locked at the session level. If the TTL for any of the messages expires, all messages related to that session are either dropped or dead-lettered based on the dead-lettering enabled on messaging expiration setting on the entity. In other words, if there's a single message in the session that has passed the TTL, all the messages in the session are expired. The messages expire only if there's an active listener. For more information, see [Message expiration](message-expiration.md).
+For session-enabled queues or topics' subscriptions, messages are locked at the session level. If the time-to-live (TTL) for any of the messages expires, all messages related to that session are either dropped or dead-lettered based on the dead-lettering enabled on messaging expiration setting on the entity. In other words, if there's a single message in the session that has passed the TTL, all the messages in the session are expired. The messages expire only if there's an active listener. For more information, see [Message expiration](message-expiration.md).
 
 ## Next steps
 You can enable message sessions while creating a queue using Azure portal, PowerShell, CLI, Resource Manager template, .NET, Java, Python, and JavaScript. For more information, see [Enable message sessions](enable-message-sessions.md). 
@@ -112,9 +112,9 @@ Try the samples in the language of your choice to explore Azure Service Bus feat
     - [Continually read through all available sessions](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/servicebus/service-bus/samples/v7/javascript/advanced/sessionRoundRobin.js)
     - [Use session state](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/servicebus/service-bus/samples/v7/javascript/advanced/sessionState.js)
 
-## Additional Resources
+## Related articles
 
-- [A blog post describing techniques for re-ordering messages that arrive out of order](https://particular.net/blog/you-dont-need-ordered-delivery)
+- [A blog post describing techniques for reordering messages that arrive out of order](https://particular.net/blog/you-dont-need-ordered-delivery)
 
-[1]: ./media/message-sessions/sessions.png
+
 

articles/service-bus-messaging/service-bus-messaging-exceptions.md

@@ -2,7 +2,7 @@
 title: Azure Service Bus - messaging exceptions (deprecated) | Microsoft Docs
 description: This article provides a list of Azure Service Bus messaging exceptions from the deprecated packages and suggested actions to taken when the exception occurs.
 ms.topic: article
-ms.date: 02/17/2023
+ms.date: 02/23/2024
 ---
 
 # Service Bus messaging exceptions (deprecated)

articles/service-bus-messaging/service-bus-messaging-overview.md

@@ -2,11 +2,11 @@
 title: Introduction to Azure Service Bus, an enterprise message broker
 description: This article provides a high-level overview of Azure Service Bus, a fully managed enterprise integration serverless message broker. 
 ms.topic: overview
-ms.date: 02/24/2023
+ms.date: 02/23/2024
 ---
 
 # What is Azure Service Bus?
-Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace). Service Bus is used to decouple applications and services from each other, providing the following benefits:
+Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics. Service Bus is used to decouple applications and services from each other, providing the following benefits:
 
 - Load-balancing work across competing workers
 - Safely routing and transferring data and control across service and application boundaries
@@ -45,9 +45,9 @@ This section discusses basic concepts of Service Bus.
 ### Queues
 Messages are sent to and received from **queues**. Queues store messages until the receiving application is available to receive and process them.
 
-![Queue](./media/service-bus-messaging-overview/about-service-bus-queue.png)
+:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-queue.png" alt-text="Diagram that shows a Service Bus queue with a sender and a receiver sending and receiving messages.":::
 
-Messages in queues are ordered and timestamped on arrival. Once the broker accepts the message, the message is always held durably in triple-redundant storage, spread across availability zones if the namespace is zone-enabled. Service Bus keeps messages in memory or volatile storage until they've been reported by the client as accepted.
+Messages in queues are ordered and timestamped on arrival. Once the broker accepts the message, the message is always held durably in triple-redundant storage, spread across availability zones if the namespace is zone-enabled. Service Bus keeps messages in memory or volatile storage until client reports them as accepted.
 
 Messages are delivered in **pull** mode, only delivering messages when requested. Unlike the busy-polling model of some other cloud queues, the pull operation can be long-lived and only complete once a message is available. 
 
@@ -56,9 +56,9 @@ Messages are delivered in **pull** mode, only delivering messages when requested
 
 ### Topics
 
-You can also use **topics** to send and receive messages. While a queue is often used for point-to-point communication, topics are useful in publish/subscribe scenarios.
+You can also use **topics** to send and receive messages. While a queue is often used for point-to-point communication, topics are useful in publish-subscribe scenarios.
 
-![Topic](./media/service-bus-messaging-overview/about-service-bus-topic.png)
+:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-queue.png" alt-text="Diagram that shows a Service Bus topic with one sender and multiple receivers.":::
 
 Topics can have multiple, independent subscriptions, which attach to the topic and otherwise work exactly like queues from the receiver side. A subscriber to a topic can receive a copy of each message sent to that topic. Subscriptions are named entities. Subscriptions are durable by default, but can be configured to expire and then be automatically deleted. Via the Java Message Service (JMS) API, Service Bus Premium also allows you to create volatile subscriptions that exist for the duration of the connection.
 
@@ -72,17 +72,17 @@ You can define rules on a subscription. A subscription rule has a **filter** to
 
 
 ### Namespaces
-A namespace is a container for all messaging components (queues and topics). Multiple queues and topics can be in a single namespace, and namespaces often serve as application containers. 
+A namespace is a container for all messaging components (queues and topics). A namespace can have one or more queues and topics and it often serves as an application container.
 
-A namespace can be compared to a server in the terminology of other brokers, but the concepts aren't directly equivalent. A Service Bus namespace is your own capacity slice of a large cluster made up of dozens of all-active virtual machines. It may optionally span three [Azure availability zones](../availability-zones/az-overview.md). So, you get all the availability and robustness benefits of running the message broker at enormous scale. And, you don't need to worry about underlying complexities. Service Bus is serverless messaging.
+A namespace can be compared to a server in the terminology of other brokers, but the concepts aren't directly equivalent. A Service Bus namespace is your own capacity slice of a large cluster made up of dozens of all-active virtual machines. It optionally spans three [Azure availability zones](../availability-zones/az-overview.md). So, you get all the availability and robustness benefits of running the message broker at enormous scale. And, you don't need to worry about underlying complexities. Service Bus is serverless messaging.
 
 ## Advanced features
 
 Service Bus also has advanced features that enable you to solve more complex messaging problems. The following sections describe these key features:
 
 ### Message sessions
 
-To realize a first-in, first-out (**FIFO**) guarantee in processing messages in Service Bus queue or subscriptions, use sessions. Sessions can also be used in implementing request-response patterns. The **request-response pattern** 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. For more information, see [Message sessions](message-sessions.md)
+To realize a first-in, first-out (**FIFO**) guarantee in processing messages in Service Bus queues or subscriptions, use sessions. Sessions can also be used in implementing request-response patterns. The **request-response pattern** 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. For more information, see [Message sessions](message-sessions.md).
 
 ### Auto-forwarding
 
@@ -106,7 +106,7 @@ A transaction groups two or more operations together into an execution scope. Se
 
 ### Filters and actions
 
-Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a **filter condition** that selects particular messages, and **optionally** contains an **action** that annotates the selected message. For each matching rule condition, the subscription produces a copy of the message, which may be differently annotated for each matching rule. For more information, see [Topic filters and actions](topic-filters.md).
+Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a **filter condition** that selects particular messages, and **optionally** contains an **action** that annotates the selected message. For each matching rule condition, the subscription produces a copy of the message, which can be differently annotated for each matching rule. For more information, see [Topic filters and actions](topic-filters.md).
 
 ### Auto-delete on idle
 

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

@@ -2,7 +2,7 @@
 title: Azure Service Bus topic filters | Microsoft Docs
 description: This article explains how subscribers can define which messages they want to receive from a topic by specifying filters. 
 ms.topic: conceptual
-ms.date: 02/28/2023
+ms.date: 02/23/2024
 ---
 
 # Topic filters and actions
@@ -11,7 +11,7 @@ Subscribers can define which messages they want to receive from a topic. These m
 
 All rules **without actions** are combined using an `OR` condition and result in a **single message** on the subscription even if you have multiple matching rules. 
 
-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 may add or update properties, or delete properties from the original message to produce a message on the subscription. 
+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:
 
@@ -33,7 +33,7 @@ Service Bus supports three types of filters:
 The following sections provide details about these filters.
 
 ### SQL filters
-A **SqlFilter** holds a SQL-like conditional expression that's evaluated in the broker against the arriving messages' user-defined properties and system properties. All system properties must be prefixed with `sys.` in the conditional expression. The [SQL-language subset for filter conditions](service-bus-messaging-sql-filter.md) tests for the existence of properties (`EXISTS`), null-values (`IS NULL`), logical `NOT`/`AND`/`OR`, relational operators, simple numeric arithmetic, and simple text pattern matching with `LIKE`.
+A **SqlFilter** holds a SQL-like conditional expression that will be evaluated in the broker against the arriving messages' user-defined properties and system properties. All system properties must be prefixed with `sys.` in the conditional expression. The [SQL-language subset for filter conditions](service-bus-messaging-sql-filter.md) tests for the existence of properties (`EXISTS`), null-values (`IS NULL`), logical `NOT`/`AND`/`OR`, relational operators, simple numeric arithmetic, and simple text pattern matching with `LIKE`.
 
 Here's a .NET example for defining a SQL filter: