SALES: 1-800-867-1380

What's New in the October 2012 Release

Updated: March 11, 2015

The Microsoft Azure Service Bus October 2012 release contains a number of new features and capabilities. This topic summarizes the new features and contains links to more information.

The Service Bus only supports a limited range of values for setting message locks. In some scenarios, you might require a longer message lock duration (via either lease extensions or higher default values). You can now renew a message lock. The following features are supported:

  • Ability to renew a lock on a message.

  • Message locks are bound to sessions.

  • Locks are obtained for 60 seconds (by default) with a maximum of 5 minutes. This is the same as the previous behavior.

A call to RenewLock updates the message lock and updates the LockedUntilUtc property once RenewLock completes.

For message sessions, the LockedUntilUtc property is populated when you accept a session using one of the client methods, such as AcceptMessageSession, or one of the factory methods, such as AcceptMessageSession.

The Service Bus now supports the ability to browse message sessions on queues and subscriptions. You can also retrieve a session whose state was updated at a given time.

For more information, see:

You can now retrieve a list of topics, queues, or subscriptions, based on an ODATA filter that you specify. For example:

IEnumerable<QueueDescription> qList = namespaceClient.GetQueues("startswith(path, 'I') eq true" );
foreach (QueueDescription qd in qList)
    Console.WriteLine("qd : {0}", qd.Path);

Using the REST API, the syntax would be:


The following scenarios are supported:

  • List all topics under a path; for example, /test1/test2.

  • List all topics updated in the last 5 minutes.

  • List all topics accessed in the last 5 minutes.

  • List all rules created in the last 5 minutes.

  • List all subscriptions under path /test1/test2 with at least one message.

  • List all topics under path /test1/test2 with at least one message.

This feature enables you to span transactions across two entities (receive, process, send, and complete in single transaction). For example:

var msftSubscription = "MSFT";
var stocksTopic = "stocks";
var messageReceiver = factory.CreateMessageReceiver(msftSubscription);
var messageSender = factory.CreateMessageSender(stocksTopic,VIAENTITYPATH);
var brokeredMessage1 = messageReceiver.Receive();
using (var scope = new TransactionScope())
    var brokeredMessage2 = ProcessMessage(brokeredMessage1);

This feature supports a general stateless workflow processing pattern (receive, process, send, complete in a single transaction). For more information, see Chaining Service Bus Entities with Auto-forwarding.

This feature enables you to create rich messaging topologies by “connecting” entities; for example from a queue/subscription to a queue/topic. For example:

QueueDescription destinationQ = new QueueDescription("myQ2");
QueueDescription sourceQ = new QueueDescription("myQ1");
sourceQ.ForwardTo = “myQ2";
NamespaceManager nm = NamespaceManager.Create();

For more information, see Chaining Service Bus Entities with Auto-forwarding.

The Service Bus now supports the ability to update existing messaging entities (queue, topic, or subscription) by disabling or re-enabling them. When you disable an entity, that entity cannot send or receive messages.

To use this feature, set the EntityStatus enumeration, then call one of the following APIs with the entity description object as a parameter:

For example:

QueueDescription qd = namespaceManager.GetQueue("myQ");
qd.Status = EntityStatus.Disabled;
qd.Status = EntityStatus.Active;

Previous versions of the Service Bus supported two types of filters for subscriptions. The correlation filter scales to large numbers but is limited to a single property/value: the SQL filter is limited to 2000 instances per topic. In some scenarios, you may want to add filters for supporting large number of combinations of property name/values. This feature now enables you to set a filter with multiple equality clauses on properties. For example:

PropertyNameOne=’ValueOne’ AND PropertyNameTwo=ValueTwo AND PropertyNameTest=’ValueThree’
CorrelationFilter filter = new CorrelationFilter();
new KeyValuePair<string, object>("name", 10));

This feature enables you to send, receive, and process messages in batches. Do use this feature, use the new API in the following list. The Service Bus provides both synchronous and asynchronous versions of the batch send and receive APIs.

For example:

IEnumerable<BrokeredMessage> messageSet;
messageSet = messageReceiver.ReceiveBatch(100); // max message count

In previous versions of the Service Bus, when a message was published to a topic, the message publication always succeeded (even if the topic message had no subscribers). In other words, the filter evaluation was performed asynchronously, after a successful message publication. If the message did not match any subscribers, the message was dropped (or deadlettered, based on the policy). In some scenarios, at the time of message publication the publisher of the message must know whether there are any subscribers. The Service Bus now enables this scenario, and if there are no subscribers at the time of message publication, the message publication fails.

To use this feature, set the EnableFilteringMessagesBeforePublishing property to true. For example:

TopicDescription td = new TopicDescription("Topic");
td.EnableFilteringMessagesBeforePublishing = true;

This new feature enables you to add or modify message properties when performing Abandon, Defer, or DeadLetter operations. This feature can be useful in scenarios in which there is an application processing error that you want to track if it causes the message to be abandoned. You can do so by adding or modifying the properties of the message, in the propertiesToModify parameter of the following APIs:

The Service Bus introduces a new class called Microsoft.ServiceBus.Messaging.MessageCountDetails. This class contains properties that enable you to retrieve details of messages from sub-queues of primary messaging entities (queues, topics, subscriptions). The MessageCountDetails properties are as follows:

public long ActiveMessageCount { get; set; }
public long DeadletterMessageCount { get; set; }
public long ScheduledMessageCount { get; set; }
public long TransferMessageCount { get; set; }
public long TransferDeadLetterMessageCount { get; set; }

The BrokeredMessage class includes a new property, IsBodyConsumed, which enables you to check to see if the message body has been consumed. For example, if a send operation fails, you can check to see if you can try resending the same message. Or, if a message is received, you can check to see if its message body has been consumed.

If either of the following occurs, IsBodyConsumed is set to true:

  1. Someone has called GetBody to consume the message body.

  2. A send operation has marked the message as consumed.

When true, then any GetBody or Send operation on that message returns an exception that indicates that the message has been consumed. You can then reconstruct the message to retry the operation (for example, Clone the message for a send).

The BrokeredMessage class includes a new method, Clone. This method enables you to send a clone of a message as a new message. The properties and body of the message are copied to the clone, although system properties are left as-is for new message so that you can selectively copy. Note that you can manually set the MessageId property after the clone operation.

Connection strings are useful for scenarios in which you want to deploy your application to one environment (for example, a test environment), then to another environment (such as a production environment). All you have to do is change the connection string in App.config to point to the new service namespace, and then restart the application.

For more information, see Configuration Connection Strings.

The WebHttpRelayBinding binding now supports JSON as a content format. To update a relay listener to receive JSON messages, set the ContentTypeMapper property of WebHttpRelayBinding. For an example, see the WebContentTypeMapper sample.

Previously, the ConnectionStatusBehavior behavior worked with only one-way bindings. You can now use it with all relay listener bindings.

Service Bus relay bindings use HTTP 1.1 “chunked” transfer encoding. Some legacy proxies support only HTTP 1.0, or do not support HTTP 1.1 chunked transfer encoding correctly. This can cause connections from clients behind such legacy proxies to the Service Bus relay to fail. To address this issue, the Service Bus relay bindings now attempt to connect using HTTPS if previous connection attempts fail. To use this feature, set the Mode value in the SystemConnectivity property to AutoDetect or Http. For more information, see the documentation for the ConnectivityMode enumeration.

Connections cache the protocol used for a successful connection, and subsequent reconnect operations initially attempt to use the cached protocol type.

If hosting behind a firewall, for this feature to work you must allow outbound HTTPS connections to port 443.

Relay connections can fail when the proxy requires authentication. Service Bus relay bindings now support connections through proxies configured for Integrated Windows Authentication or for Negotiate.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft