SALES: 1-800-867-1380

What's New in the Azure SDK 2.3 Release (April 2014)

Updated: August 18, 2014

The Microsoft Azure Service Bus April 2014 ( SDK 2.3) release contains a number of new features and capabilities. This topic summarizes the new features and contains links to more information.

Scenarios that are built around a request-reply pattern require low end-to-end latency. To further reduce end-to-end latency, Service Bus now enables you to specify that messages are temporarily stored in memory instead of immediately being written to stable storage. In addition to low latency scenarios, this feature has the following advantages:

  • If a message is sent to a queue or topic, the message is cached in memory.

  • If a message remains in the queue for more than a few seconds, it is automatically written to stable storage, thus protecting it against loss due to an outage.

Messages that are consumed within a few seconds are not written to stable storage.

If a message is sent to a topic with multiple subscriptions, and is subsequently received from some but not all subscriptions, the message is written to stable storage.

The following code shows how to create an express queue:

QueueDescription qd = new QueueDescription(QueueName);
qd.EnableExpress = true;
namespaceManager.CreateQueue(qd);

If you are processing messages with critical information that must not be lost, you can force Service Bus to immediately persist the message to stable storage, by using the Microsoft.ServiceBus.Messaging.BrokeredMessage.ForcePersistence property.

ImportantImportant
To enable this feature, you must use Microsoft.ServiceBus.dll version 2.3.2. If you download the latest NuGet package, you will automatically have the latest version. For more information, see Using the NuGet Service Bus Package. Also, when using REST over HTTP, specify api-version=2014-04.

For more information, see

OnMessage introduces receive semantics for sessions.

OnMessage now uses asynchronous operations to help improve performance. This implies a change to the message completion behavior; user code is not invoked until the Complete operation is either complete, or failed.

This release of Service Bus introduces new push-style APIs for consuming messages from sessions.

The following code shows how to write a session-aware OnMessage() method. The sample shows asynchronous code:

class MySession : MessageSessionAsyncHandler
{  
    protected override async Task OnMessageAsync(MessageSession session, BrokeredMessage message)
    {
        // Do the work here
    }
}

class Program
{
    public static void Main(string[] args)
    {
        QueueClient client = …;
 
        client.RegisterSessionHandler(typeof(MySession));
    }
}

The following sample code shows how to implement OnClose()/OnSessionLockLost() semantics in order to handle graceful or ungraceful terminations:

class MySession : MessageSessionAsyncHandler
{ 
    protected override async Task OnMessageAsync(MessageSession session, BrokeredMessage message)
    {
        // Do some work here
    }

    protected override async Task OnCloseSessionAsync(MessageSession session)
    {
        Stream stream = …;
        await session.SetStateAsync(stream);
    }

    protected override async Task OnSessionLockLostAsync()
    {
        // Perform client cleanup here
    }
}
 
class Program
{
    public static void Main(string[] args)
    {
        QueueClient client = …;

        client.RegisterSessionHandler(typeof(MySession));
    }
}

In addition, QueueClient and SubscriptionClient now include the following overloaded method to register a session handler:

public void RegisterSessionHandler(Type handlerType);
 
public void RegisterSessionHandler(Type handlerType, SessionHandlerOptions options);

Asynchronous versions of these API are also provided, because RegisterSessionHandler takes some time to register the receiving session. As such, you may receive an exception if the entity does not exist, or if the entity does not support sessions.

public Task RegisterSessionHandlerAsync(Type handlerType);

public Task RegisterSessionHandlerAsync(Type handlerType, SessionHandlerOptions options);

For more information, see

The Auto-forwarding feature enables you to chain a subscription or queue to another queue or topic that is part of the same service namespace. When auto-forwarding is enabled, Service Bus automatically removes messages that are placed in the first queue or subscription (source) and puts them in the second queue or topic (destination). See the Chaining Service Bus Entities with Auto-forwarding topic. With this release of Service Bus, you can now enable auto-forwarding from dead letter queues by setting the Microsoft.ServiceBus.Messaging.QueueDescription.ForwardDeadLetteredMessagesTo property on the QueueDescription or SubscriptionDescription objects.

namespaceManager.CreateQueue(DestinationQueueName);
QueueDescription qd = new QueueDescription(QueueName) { ForwardDeadLetteredMessagesTo = topic2.Path };
namespaceManager.CreateQueue(qd);

For a working example, see the Service Bus Autoforwarding sample.

For more information, see

The Microsoft.ServiceBus.ConnectivityMode enumeration enables you to automatically select between the TCP, HTTP and HTTPS connectivity modes based on an auto-detection mechanism that probes whether either connectivity option is available for the current network environment. This is now supported for queues and topics in addition to relay.

To help increase throughput when using Service Bus, you can use client-side batching (as described in the Best Practices for Performance Improvements Using Service Bus Brokered Messaging topic). This feature reduces the number of protocol transmissions when sending messages, by batching multiple messages into one. With this release of Service Bus, client-side batching is now supported in REST scenarios.

For example, the following code shows how to use REST to send a batch of messages:

string msg1 = "{\"Body\":\"This is the first message.\",\"BrokerProperties\":{\"Label\":\"M3\"}}";
string msg2 = "{\"Body\":\"This is the second message.\",\"BrokerProperties\":{\"Label\":\"M4\"},\"UserProperties\":{\"Priority\":\"Low\"}}";
byte[] serviceBusHttpMessageBody = Encoding.UTF8.GetBytes("[" + msg1 + "," + msg2 + "]");
WebClient webClient = new WebClient();
webClient.Headers[HttpRequestHeader.Authorization] = token;
webClient.Headers[HttpRequestHeader.ContentType] = "application/vnd.microsoft.servicebus.json";
webClient.UploadData(address + "/messages" + "?timeout=60" + ApiVersion, "POST", message.body);

With this release, the message body must be valid JSON and follow a convention to describe each message. There are no common message properties. Each message has its own set of broker properties and custom properties, which must be part of the JSON string.

For a working example, see the Service Bus HTTP Client sample.

For more information, see

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