DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Managing Distributed System Locks With Azure Storage
  • What Is Azure Content Delivery Network Service?
  • Test Automation: Maven Profiles and Parallelization in Azure Pipelines Using IaaS
  • Configuring Anypoint Platform as an Azure AD Service Provider SSO

Trending

  • Key Considerations in Cross-Model Migration
  • Scaling in Practice: Caching and Rate-Limiting With Redis and Next.js
  • How to Format Articles for DZone
  • Scalable System Design: Core Concepts for Building Reliable Software
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. Azure Service Bus – As I Understand It: Part II (Queues & Messages)

Azure Service Bus – As I Understand It: Part II (Queues & Messages)

By 
Gaurav Mantri user avatar
Gaurav Mantri
·
Jul. 02, 15 · Interview
Likes (0)
Comment
Save
Tweet
Share
8.5K Views

Join the DZone community and get the full member experience.

Join For Free

continuing from my previous post about azure service bus, in this post i will share my learning about queues & messages. the focus of this post will be about some of the undocumented things i found as we implemented support for queues and messages in cloud portam .

queues

as mentioned in my previous post, queues is the simplest of the azure service bus service and kind of compares with azure storage queue service in the sense that it provides a unidirectional messaging infrastructure where a publisher publishes a message and the message is received by a receiver. there can be many receivers ready to receive the messages however one receiver can only receive a message. no two receivers can receive a single message simultaneously.

now some learning about queues.

queue name

a queue name can be up to 260 characters in length and can contain letters, numbers, periods (.), hyphens (-), and underscores (_) . a queue name is case-insensitive.

queue size

when creating a queue, you must define the size of the queue. queue size could be one of the following values: 1 gb, 2 gb, 3 gb, 4 gb or 5 gb . a queue size can’t be changed once the queue is created. however if you create a “ partition enabled queue ” then service bus creates 16 partitions thus your queue size is automatically multiplied by 16 and your queue size becomes 16 gb, 32 gb, 48 gb, 64 gb or 80 gb depending on the size you selected (this confused me initially :)).

queue properties

a service bus queue has many properties. some of the properties can only be set during queue creation time while some of the properties can only be set if you are using “standard” tier of service bus.

image

image

(above are the screenshots from cloud portam for creating a queue)

status

indicates the status of a queue – active or disabled . once a queue is disabled, it cannot send or receive messages.

max delivery count (maxdeliverycount)

indicates the maximum number of times a message can be delivered . once this count has exceeded, message will either be removed from the queue or dead-lettered. the way i understand it is this property is used to manage poison messages. if a message is not processed successfully by receivers for “x” number of times, just move it somewhere else for further inspection or remove it.

message time to live (messagettl)

indicates a time span for which a message will live inside a queue . if the message is not processed by that time, it will either be removed or dead-lettered. one interesting thing i noticed is that if you’re using “standard” tier, a message could live forever in a queue however in “basic” tier, a message can only live for a maximum of 14 days .

lock duration (lockduration)

indicates number of seconds for which a message will be locked by a receiver once it receives it so that no other receiver can receive that message . it essentially gives the receiver time to process the message. once this elapses, message will be available to be received by another receiver. maximum value for lock duration can be 5 minutes / 300 seconds .

enable partitioning (enablepartitioning)

indicates if the queue should be partitioned across multiple message brokers . as mentioned above, service bus automatically creates 16 partitions if this is enabled. this also results in maximum size of the queue increase by a factor of 16. this property can only be set during queue creation time .

enable deadlettering (enabledeadlettering)

indicates if the messages in the queue should be moved to dead-letter sub queue once they expire. if this property is not set, then the messages will be removed from the queue once they expire.

enable batching (enablebatchedoperations)

indicates if server-side batched operations are supported. this is used to improve the throughput of a queue as service bus holds the messages for up to 20ms before writing/deleting them in a batch.

enable message ordering (supportordering)

indicates if the queue supports ordering.

requires duplicate detection (requiresduplicatedetection)

indicates if the queue requires duplicate detection. this property can only be set during queue creation time and is only available for “standard” tier.

enable express (enableexpress)

indicates if the queue is an express queue. an express queue holds a message in memory temporarily before writing it to persistent storage. this property can only be set during queue creation time and is only available for “standard” tier.

requires session (requiressession)

indicates if the queue supports the concept of session. this property can only be set during queue creation time and is only available for “standard” tier.

auto delete queue

this property specifies a time period after which an idle queue should be deleted automatically by service bus . minimum period allowed is 5 minutes. this can only be set for “standard” tier .

duplicate detection history time window (duplicatedetectionhistorytimewindow)

defines the duration of the duplicate detection history. this can only be set for “standard” tier .

forward messages to queue/topic (forwardto)

you can use this property to automatically forward messages from a queue to another queue or topic. when setting this property, the queue/topic must exist in the account. this can only be set for “standard” tier .

forward dead-lettered messages to queue/topic (forwarddeadletteredmessagesto)

you can use this property to automatically forward dead-lettered message to another queue or topic. when setting this property, the queue/topic must exist in the account.

user metadata (usermetadata)

you can use this property to define any custom metadata for a queue.

following table summarizes property applicability by tier and whether they are editable or not.

property tier editable?
size basic, standard no
status basic, standard yes
max delivery count basic, standard yes
message time to live basic, standard yes
lock duration basic, standard yes
enable partitioning basic, standard no
enable deadlettering basic, standard yes
enable batching basic, standard yes
enable message ordering basic, standard yes
requires duplicate detection standard no
enable express standard no
require session standard no
auto delete queue standard yes
duplicate detection history time window standard yes
forward messages to queue/topic standard yes
forward dead-lettered messages to queue/topic basic, standard yes
user metadata basic, standard yes

to learn more about these properties, please see this link: https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.queuedescription.aspx .

messages

the way i see it, messages are the entities that contain information about the work a sender wants a receiver to do. as mentioned earlier, a sender sends a message to a queue and a receiver will receive the message. at any time, a message will be received by one and only one receiver.

message processing

there’re two ways by which a receiver will receive a message: peek and lock & receive and delete .

peek and lock

in peek and lock mode, the message is locked by the receiver for a duration specified by queue’s “ lock duration ” property or in other words under this mode a message is hidden from other receivers for a duration specified by lock duration. the receiver then would process the message and after that a receiver would mark the message as “ complete ” which essentially deletes the message from the queue. if the “lock duration” expires, other receivers will be able to fetch this message.

receive and delete

in receive and delete mode, once the message is received by a receiver it will be deleted from the queue automatically. if a receiver fails to process that message, then the message is lost forever. so unless you’re sure of receiver’s functionality that it will never fail or you don’t care if the message is processed successfully or not, use this mode cautiously.

message composition

a message in service bus consists of 3 things – message body, standard properties and custom properties. message body is the actual content of the message. there are some predefined properties of a message and those fall under standard properties. apart from that you can define custom properties on a message which are essentially a collection of name/value pairs. total size of a message is 256 kb.

message properties

now let’s take a look at some of the standard properties of a message that i found interesting.

message id

this is the identifier of a message. you can set it at the time of sending a message. because it is an identifier, one would assume that it needs to be unique but that’s not the case. different messages can have same message id.

sequence number

when a message is created, service bus assigns a number to a message. that number is stored in this property. please note that it is a read-only property.

message time to live (message ttl)

this is the time period for which a message will remain in the queue. if you recall, you can also define a default message time-to-live at queue level also. service bus actually picks the lower of the two values as message ttl. for example, if you have defined that a message will expire after 14 days at queue level but 5 minutes at the message level then the message will expire after 5 minutes.

lock token

whenever a message is received by a receiver in “ peek and lock ” mode, service bus returns a (lock) token that must be used to perform further operations (e.g. delete message or dead-letter message etc.) on that message. this token is valid for a duration specified by “ lock duration ” property. after the lock duration expires, the lock token becomes invalid and any attempt to use this token for performing any allowed operations will result in an error. once a lock token expires, a receiver must receive the message again.

there are other properties as well which i have not included for the sake of brevity. for a complete list of properties, please see this link: https://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage_properties.aspx .

summary

that’s it for this post. in the next posts in this series, i will share my learning about topics and other service bus services. so stay tuned for that! again, if you think that i have provided some incorrect information, please let me know and i will fix them asap.

Property (programming) Receiver (information theory) azure Time to live Lock (computer science) Express

Published at DZone with permission of Gaurav Mantri, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Managing Distributed System Locks With Azure Storage
  • What Is Azure Content Delivery Network Service?
  • Test Automation: Maven Profiles and Parallelization in Azure Pipelines Using IaaS
  • Configuring Anypoint Platform as an Azure AD Service Provider SSO

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!