planetgeek.ch

Explains where messages go when they can’t be transferred to the destination, for more posts in this series go to Contents. A while ago, I introduced the concept of deadlettering messages in which I talked about where messages go in case of message expiry, reaching the maximum delivery count, or they were forcefully dead lettered. In the posts about atomic sends as well as send via, I showed how a transaction scope can be used to group send operations together into atomic units that...

Shows how to query runtime information using the management client, for more posts in this series go to Contents. Quite early in this series I introduced the ManagementClient to create queues for example. Besides being able to create entities like queues, topics and subscriptions the management client provides the capability of querying runtime information from namespaces, queues, topics and subscriptions. The ability to query runtime information is quite handy for diagnostics purposes, check...

With SendVia, it is possible to create an atomic transaction between the incoming message and outgoing messages, for more posts in this series go to Contents. In scenarios where transactional processing is required for an incoming message that would generate some outgoing messages, the incoming and outgoing messages should all succeed or rollback. Failure to do so would either create duplicate processing (failure to complete the incoming message) or ghost messages (failure to revert the...

Shows how to batch multiple messages together into one single operation against Azure Service Bus, for more posts in this series go to Contents. In the article about atomic sends, we talked about the fact that each send operation executed against Azure Service Bus can fail and potentially has to be retried. Another important aspect though that wasn’t covered in the previous article is that every send operation has latency costs associated with it. Let’s assume we want to send ten...

Shows how to atomically send messages as a group, for more posts in this series go to Contents. This topic is best illustrated by directly diving into some code. var client = new QueueClient(connectionString, destination); var message = new Message(Encoding.UTF8.GetBytes("Deep Dive 1")); await client.SendAsync(message); message = new Message(Encoding.UTF8.GetBytes("Deep Dive 2")); await client.SendAsync(message); In the above code, a QueueClient is used to send two messages...

Shows how to create topologies by combining subscriptions with forwarding, for more posts in this series go to Contents. In the previous post we looked at how we can leverage topics and subscriptions together with rules to create powerful message-based solutions. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Messages are received from a subscription identically to the way they are received from a queue. The implication of the...

Shows how to publish and subscribe with topics, for more posts in this series go to Contents. In contrast to queues, in which a single consumer processes each message, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. The pattern is useful for scaling to large numbers of recipients, and each published message is made available to each subscription registered with the topic. The main benefits are: The publisher...

Introduces the concept of forwarding from one entity to another, for more posts in this series go to Contents. Queues and Subscriptions (more about those later) have the possibility to become what I call “forwarding-only” entities. An entity can be set into the forwarding mode by setting the property ForwardTo to a destination. var description = new QueueDescription("Hop"); await client.CreateQueueAsync(description); description = new QueueDescription("Hop0"); await client...

Explains where messages got when certain conditions are met, for more posts in this series go to Contents. If we are using queuing, we certainly don’t want to lose messages. After all, those queues decouple the sender from the receiver by persisting the business intent messages and allowing them to handle them whenever the receiver has time. But what if: The receiver doesn’t pick up the message before the message’s time to live is expired (Expiry)The receiver could not...

Explains how messages can expire by associating a time to live with the message, for more posts in this series go to Contents. There are multiple ways of how messages can “disappear” from a queue. The most obvious one is that a message in the queue was received by a client and successfully acknowledged. There is another one that might be not that obvious and can even be leveraged to create clever designs: It is called message expiry or time to live. If not specified otherwise...