DEV Community: Leah Robert

PubSub+ Message Handling Features: Reject-Message-to-Sender-on-Discard

Leah Robert — Thu, 19 Aug 2021 14:11:27 +0000

Thus far in the message handling features blog series we have looked at message expiry and dead message queues. In this blog post we will cover the persistent messaging feature Reject Message to Sender on Discard. A long name, and an important endpoint property for defining certain scenarios when publishers should receive negative acknowledgements. For short, we will refer to the feature in this blog as Reject-to-Sender.

What is the Reject-to-Sender endpoint property?

Reject-to-Sender defines when a publisher should receive a negative acknowledgement if a message is rejected from an endpoint. This property is typically used when there are multiple consumers that require the exact same data. The configuration could look something like the below; each consumer has its own queue, and each queue has the same subscription.

Each of these consumers will receive the same messages because they are using persistent delivery and they all have the same subscription. However, if one consumer is slow or offline, its queue could fill up.

In this scenario, messages could still be stored in Q1 and Q2, but as Q3 is full, it would not have any room for new messages. Reject-to-Sender being enabled on these queues ensures that a message is stored on all 3 queues, or none of the queues. Almost like an ‘all or nothing’ property for endpoints that share subscriptions.

When the message is rejected from Q3, an error (or negative acknowledgement) is sent back to the publisher and the message is not stored on any of the three queues; it is then up to the publisher to resend the message.

Now, if Q3 had Reject-to-Sender disabled in this scenario, the message would be stored on Q1 and Q2, and the publisher would not receive any error message. This is regardless of whether Q1 and Q2 have the Reject-to-Sender property enabled or not.

How do I use Reject-to-Sender?

Reject-to-Sender is the property of a guaranteed endpoint and can be enabled/disabled as an endpoint setting. There are three options when configuring Reject-to-Sender:

‘When Queue Enabled’ refers to the queue admin status – if the queue is enabled, Reject-to-Sender is enabled
- If the queue is administratively shutdown, this queue will not have an impact on sending negative acknowledgements to the publisher. Negative acknowledgements are only sent if a message is rejected & the queue is enabled. This is the most common setting for the Reject-to-Sender property.
‘Always’ treats Reject-to-Sender as enabled even when the queue is administratively shutdown
- This is the least common setting for this property as messages would always be negative acknowledged to the publisher when a queue is shutdown.
‘Never’ treats Reject-to-Sender as disabled
- This setting is used when a queue should not be included in the ‘all or nothing’ functionality. An example is when a queue bridges data from a Production environment to UAT/Test. If this queue were to fill up, you would not want it to affect Production processing of data.

By default, Reject-to-Sender is set as ‘When Queue Enabled’ for queues, and is disabled for topic-endpoints.

When messages are not able to be saved to a queue, the queue statistics will increment.

There is another scenario to consider: a message is published as persistent, however there is no matching subscription on the broker. For this scenario, there is another Reject-to-Sender property located in the authorization object called a Client-Profile. While I won’t be going into full detail of the Client-Profile object in this blog, the property name is called Reject-Messages-to-Sender-On-No-Subscription-Match-Discard. This property ultimately provides the same behaviour as the queue property, but for specific scenarios where there are no subscriptions for a published persistent message.

If you found this post useful, visit the queue properties section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.

The post PubSub+ Message Handling Features: Reject-Message-to-Sender-on-Discard appeared first on Solace.

PubSub+ Message Handling Features: Dead Message Queues

Leah Robert — Tue, 15 Jun 2021 14:35:32 +0000

In the first blog in this series, I explained the concept of message expiry, or message-TTL. Here I’ll look at dead message queues (DMQs), which assumes you have background knowledge on Solace endpoints and Solace persistent messaging.

What is a Dead Message Queue?

A dead message queue, sometimes referred to as a dead letter queue, is an endpoint to store messages that have lost delivery eligibility in their original endpoint, and stores messages for special processing or delayed consumption.

You might be wondering how a message can lose delivery eligibility, especially when it is originally published as persistent. There are two ways messages can be deemed ineligible for delivery:

** **** Message Expiry:** The first post in this series goes into more detail on message expiry, but as a summary it is when a message is published to an endpoint with a timer, or time-to-live. When this timer expires, the message is removed from the original endpoint and can be deleted or can be moved to a DMQ.
Poison Message: The second reason a message can lose delivery eligibility is if it is redelivered from an endpoint to a consumer too many times. This scenario could occur when a consumer is unable to process a message and crashes before sending an application acknowledgement. When that application reconnects to the endpoint, it will receive the same message and would be stuck in a loop. In this case, the message is referred to as a poison message. To ensure an application does not get stuck in this loop, an endpoint can be set to redeliver a message a maximum number of times with the setting ‘Maximum Redelivery Count’. Once exceeded, the message will be removed from the endpoint or can be moved to a DMQ.

How do I use a Dead Message Queue with Solace PubSub+ Event Broker?

A DMQ on Solace PubSub+ Event Broker is configured as a normal queue and can be created in the same manner on the Queue page of PubSub+ Broker Manager.

Once created, the DMQ is configured on the original endpoint in the ‘DMQ Name’ field.

Note that messages will not be moved into a DMQ unless they are published with the flag ‘DMQ-Eligible’. Without this set, the messages will be deleted from the original queue when they lose delivery eligibility.

That is an important point that bears repeating: Messages must be DMQ-Eligible!

** ** If you want messages that expire to go to a DMQ, you need:

Queue with ‘Respect-TTL’ enabled, a DMQ configured, and optionally a ‘Maximum-TTL’ specified
Published messages can have a ‘Message-TTL’ and must be ‘DMQ-Eligible’

If you want messages that reach the maximum redelivery count to go to a DMQ, you need:

Queue with ‘Maximum Redelivery Count’ set (Redeliver Forever disabled), and a DMQ configured
Published messages must be ‘DMQ-Eligible’

When a message moves from an endpoint to its DMQ, the below highlighted statistics will reflect this.

Why would I use a DMQ?

A DMQ is useful for special processing when messages are unable to be consumed on their original endpoint. This could be for expedited processing of orders, or the DMQ consumer may process the message in a different way than the original consumer.

Take for example an order management system that must process orders in a timely manner. For orders that are not processed in the desired amount of time, they could be expired to a dead message queue for expedited processing.

Another good example is error handling: a message that can’t be consumed from the original queue is moved to a DMQ to be inspected and processed.

Conclusion

I hope I’ve helped you feel more comfortable with what DMQs are and how to use them. If you found this post useful, you might want to check out the message properties section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community!

The post PubSub+ Message Handling Features: Dead Message Queues appeared first on Solace.

PubSub+ Messaging Handling Features: Message Expiry

Leah Robert — Tue, 11 May 2021 13:15:07 +0000

Message handling features can help administrators and developers control how messages behave on the event broker and how they are received by consumers. This is the first in a series of blog posts in which I’ll introduce the various message handling features supported by Solace PubSub+ Event Brokers, starting with message expiry. Before reading this you should be familiar with both Solace endpoints and Solace persistent messaging.

What is Message Expiry?

Message expiry is a timer that dictates the lifespan of the message. The message will persist on an endpoint until that timer expires. Without this timer, a message will persist on a Solace endpoint indefinitely, or until it is consumed by an application or deleted by an administrator.

Message expiry is also commonly referred to as ‘message time-to-live’ or ‘message-TTL’.

How do I use message expiry with Solace PubSub+ Event Broker?

When considering message expiry, you need to consider a couple of required configurations. First, your endpoint must ‘Respect-TTL’ – this setting informs the endpoint to actively check messages for a TTL value. Next, you must set the TTL for the message.

There are two options to set the TTL:

Set ‘Maximum TTL’ on the endpoint. This will apply to all messages that are stored in the endpoint and is measured in seconds.
The publisher optionally sets the ‘Message-TTL’ on the message before sending it. This method allows the publisher to decide how long each message should live and if each message requires a TTL. This value is measured in milliseconds.

It is possible to set both the Message-TTL and the queue Max-TTL. The lower of the two is used for expiry.

Once a message has expired, the default behavior is that the message is deleted from the endpoint. It is also possible to have the message move to a Dead-Message-Queue, for special error or behaviour handling. When a message is expired from the endpoint, the discard statistics will reflect this.

What are some use cases for message expiry?

Message expiry, especially when set on the queue itself, is particularly useful in development environments where messages are sent to queues and are not consumed. To prevent the queue from filling up, you can use TTL to remove messages from a development queue as needed.

A use case example of message expiry could be an order management system that must process orders in a timely manner. For orders that are not processed in the desired amount of time, they could be expired to a Dead-Message-Queue for special, expedited processing or for error handling.

Another example could be an application that receives flight statuses. If a flight status is not consumed within a couple of hours, possibly due to the consuming application being unavailable, the flight status may no longer be relevant and is no longer required. The message could then be expired and removed from the endpoint.

If you found this post useful, visit the message properties section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, post them to the Solace Developer Community.

The post PubSub+ Messaging Handling Features: Message Expiry appeared first on Solace.

Understanding Solace Delivery Modes: Promotion & Demotion

Leah Robert — Fri, 23 Oct 2020 13:02:49 +0000

In a previous blog post I explained the two delivery modes that Solace supports: direct messaging and persistent messaging, which is also called guaranteed messaging. In this blog post I will explain the promotion and demotion of messages.

Before diving in to message promotion and demotion, it’s important to understand the basics of publish/subscribe messaging. In short, it’s a message exchange pattern that lets applications send (publish) information (as messages) to a topic (a message property represented by a text string) that indicates what the message is about, and applications that want that kind of information can subscribe to receive all messages with topics that indicate information they want to receive. This makes it easy and efficient to fan messages out to any number of interested applications without any configuration or overhead.

Another thing you need to understand before we dive in to message promotion and demotion is that topics can be mapped to queues. A topic subscription (i.e. that is, the means by which applications express interest in a given topic) can be applied to a queue. A queue is an object on the Solace PubSub+ Event Broker that stores messages (hence the term “persistent”) for an application to receive later. Applying a topic subscription to a queue means messages matching that subscription will be received and buffered by the queue.

Message Promotion

Message promotion occurs when a message that was published as direct ends up on an endpoint, which effectively guarantees its delivery. A direct message can end up on an endpoint when the endpoint’s topic subscription matches the message’s topic. In the below example, we can see the direct message is published to topic “a/b/c”. The queue subscription is “a/b/>”, which matches the published topic. The message is still received by the direct subscriber because of the subscription “a/b/c” and is also saved in the queue.

It is important to note that the message saved onto the queue has a change in delivery mode. Because the message was published as direct but is now saved in a queue making it act as a guaranteed or persistent message, the event broker changes the delivery mode to Solace ‘non-persistent’ to indicate to the consuming application that the message was promoted.

Message Demotion

Message demotion, on the other hand, occurs when a message published as persistent matches a direct topic subscription. In this case the message delivery mode is changed from ‘persistent’ to ‘direct’ for the direct subscriber, but the message is still acknowledged to the publishing application once it has been saved in the receiving endpoint(s).

Considerations

It’s important to know that direct messages, even when promoted, are never acknowledged to the initial publisher. When a higher quality of service is required, you should always publish messages as persistent.

You need to be wary of message promotion, because it can put unwanted backpressure on saving messages to an endpoint. Message promotion should be avoided whenever possible by ensuring that endpoint subscriptions do not match published direct messages.

Conclusion

I hope I’ve helped you understand the concept of message promotion and demotion. If you found this post useful, visit this section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about message promotion and demotion, our developer community is a great place to pose questions and see what your fellow developers are talking about.

The post Understanding Solace Delivery Modes: Promotion & Demotion appeared first on Solace.

Understanding Solace Delivery Modes: Direct Messaging vs. Persistent Messaging

Leah Robert — Thu, 24 Sep 2020 19:21:28 +0000

Solace supports two main delivery modes, also known as qualities of service: direct messaging that delivers a message one time at most, and persistent messaging that guarantees delivery at least once.

This short blog series will provide an overview of the delivery modes and an overview of message promotion and demotion.

Direct Messaging

Direct messaging is over Transmission Control Protocol (TCP) and is therefore a reliable method of moving data. You can think of it as a ‘fire and forget’ model, where the publishing application sends the data to the Solace event broker and does not expect confirmation that the message was received.

Direct messaging is used when data is not always required on the consuming end – as an example, consider GPS location updates. A consuming application would still have enough information about a vehicles location even if it misses a few updates, so receiving every single message is nice, but not critical, in this scenario.

Persistent Messaging

Persistent messaging is also over TCP but has an additional set of acknowledgements beyond those used by TCP itself. When a message is sent as persistent, the broker acknowledges receipt of that message when the message is saved in an endpoint on the broker.

To ensure message delivery, a message is also acknowledged by a consuming application once it has been received from the Solace event broker and has been processed. There are two acknowledgments that occur on the consuming side; one to confirm the application has received the message (Transport/API ACK), and one to confirm the application is done with the message (Application/Client ACK). The first acknowledgement allows the Solace event broker to send more messages to the consuming application – this increases efficiency as the consuming application will have buffered a set of messages ready to be processed. The second acknowledgement is sent when the consuming application is done processing the message and no longer requires that data – this acknowledgment removes the message from the endpoint on the Solace event broker.

Persistent messaging with Solace occurs between the publishing application and the broker, and between the broker and the consuming application. If the consuming application is not connected or cannot keep up with the publishing application, the messages are stored in endpoints on the Solace event broker.

Persistent messaging is used when data must be received by the consuming application, even if they are offline, and data can’t be lost. An example is an online store where any loss in messages could mean a missed revenue opportunity, lost customer, or a too-late decision to replenish inventory of a hot-selling product.

Exactly Once Delivery

In most situations, Solace’s persistent messaging quality of service provides exactly once delivery of messages where data is received, processed, and acknowledged. However, a message can be sent to a consumer multiple times when acknowledgements are not received as expected by the broker.

If a message is sent to a consuming application and the API ACK is received, the broker knows the consuming application has the message but has not yet completed processing of that message. If the consuming application were to disconnect from and reconnect to the broker, Solace would resend the message to the consuming application to ensure it will be processed. In this situation, the consuming application would need to verify if it has already processed the data and send the Application ACK to the broker to remove the message from the endpoint.

This safety mechanism ensures the data is received by the consuming application and there is no message loss. Consuming applications should have duplicate message handling for this exact situation. Solace also supports transactions, should your message flow require ACID properties.

How Do I Set Delivery Mode?

On the publishing side, the delivery mode is dependent on the message property ‘Delivery Mode’. This property can be set to ‘DIRECT’ or to ‘PERSISTENT’. Below is an example of how this is set in the Solace Java API, JCSMP:

Message.setDeliveryMode(‘PERSISTENT’);

Note: queues can have topic subscriptions applied to them to get a publish-subscribe persistent messaging exchange pattern. You can read more in this blog.

The consuming side delivery mode is dependent on how the consuming application subscribes to the data. If the application applies a topic subscription to its connection, it receives data via direct messaging. If the application binds to an endpoint, it will receive the data in a persistent manner.

To summarize the Solace delivery modes, direct messaging is an example of at most once delivery, where data is sent in a reliable manner, but is not guaranteed. Guaranteed or persistent messaging is an example of at least once delivery, where data will be guaranteed to reach its destination.

In the next blog post in this series, I will explain how messages can be promoted and demoted. I hope this post has helped you understand the concept of message delivery modes. If you found this post useful, visit this section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about message delivery modes, try posting them to the Solace Developer Community.

The post Understanding Solace Delivery Modes: Direct Messaging vs. Persistent Messaging appeared first on Solace.

Understanding Solace Endpoints: Message Queue Access Types for Consumers

Leah Robert — Wed, 29 Apr 2020 12:00:00 +0000

The concept of message queues is fundamental in message-oriented middleware (MOM) and a constant topic of discussion for Solace users. Generally speaking, a queue is defined as a storage area where a message is stored until it is consumed by an application, or it expires. A queue provides the guarantee that the message will never be lost even if the consuming application is unavailable or if the message broker crashes. Note that in addition to writing this blog post, I’ve also presented this concept in a video you can watch here.

Solace endpoints are objects created on the event broker to persist messages. There are two types of endpoints: a queue endpoint (usually just called a queue) and a topic endpoint. I detailed the differences here if you want to learn more, and in this post I’ll explain the two consumer patterns you have to choose from, how they differ, and when you should use each.

Solace Message Queue Access Types

In Solace PubSub+ Event Broker, a message from a queue can be consumed by only one application, even though multiple applications can be bound to the queue. Based on the use case, a queue can have two access types for consumers: exclusive and non-exclusive.

Exclusive Queue (Fault Tolerance Pattern)

When an application disconnects from the event broker, the endpoint it was connected to will buffer and save the messages destined for that application. If the application does not connect for a long period of time and the incoming message rate does not slow, the queue could run the risk of filling up. There is also the case where a consuming application cannot have downtime when processing time-sensitive data.

Using an exclusive queue, a developer could connect multiple instances of an application to the same queue to ensure messages are always processed. The first instance to connect, or bind, to the queue will receive all messages; should that instance of the application disconnect, the next instance that connected to the queue is prepared to take over activity and start consuming. This provides a fault tolerant method to consuming data from a queue without any downtime.

Note: Topic endpoints do not support multiple consumers when set as exclusive, therefore this fault tolerant consumer pattern only applies to queues.

For the developers out there, it may be useful to know there is an Active Consumer Indication which indicates to a previously standby consumer they are now the active consumer. This can be useful for grouped applications to function properly in a fault tolerant consumer pattern.

Non-Exclusive Queue (Competing Consumer Pattern)

For some use cases, the ingress rate (publish message rate) may be too fast for a single endpoint consumer to keep up. It may be required to have multiple instances of an application share an endpoint and consume data in a load-balancing manner.

A Solace non-exclusive endpoint allows multiple connections to bind to it and messages are round robin distributed to those connected applications. There is also a consideration for the speed of each consuming application, meaning that messages will be sent to the consumer based on how fast or slow the consumer is. Based on the acknowledgment rate from the consumer, the broker will deliver the messages at the appropriate rate. This is often referred to as a competing consumer pattern.

For example, in the below diagram, both Application A and Application B will get messages. If both applications are processing messages at the same rate, the broker will deliver an equal number of messages to both apps. However, if Application B slows down, then based on the acknowledgment rate back from Application B, the broker will be able to identify Application B as a slow consumer and send the messages at the appropriate rate to Application B. The broker takes care that consumer applications are never pressured, and therefore acts as a shock absorber.

Both a queue and topic endpoint support this ability. While its default state is to support only one consumer, a non-exclusive topic endpoint can support multiple consumers.

Considerations

The maximum number of consumers on a single endpoint can be configured on the endpoint itself, with the following exceptions which only allow for one consumer:

The endpoint is an exclusive topic endpoint
The endpoint is a non-durable endpoint

Access Type Setup

The good news is that all this complex logic is done by the broker behind the scene without any manual intervention by the administrator. The only thing that an administrator must decide is whether the queue is exclusive or non-exclusive. This can be done while the queue is being created or can also be done at a later date.

This Solace message queue property can be changed without any downtime. Changing this at runtime will cause consumers to disconnect, however, properly written applications should automatically reconnect; when they do, the queue will start behaving with the changed value.

Which consumer pattern should you use?

The access type to use will depend on the exact use case. Both access types have their benefits. The main deciding factor should be whether message ordering is important and if applications need to run in parallel to increase the overall throughput.

These two access types can be combined together for some complex use case requirements like sticky load balancing or consumer group pattern. Read the blog post on sticky load balancing for a detailed explanation.

Conclusion

I hope this post has helped you understand the concept of access types, and how and when each access type should be used. If you found this post useful, you can visit the queues section of our docs and our PubSub+ for Developers page for more information. You can also check out some sample code on Github.

You can also read more in my series about understanding Solace endpoints by visiting the posts below:

Here’s the video version of this post that I mentioned above:

The post Understanding Solace Endpoints: Message Queue Access Types for Consumers appeared first on Solace.

Understanding Solace Endpoints: Durable vs. Non-Durable

Leah Robert — Tue, 25 Feb 2020 19:14:30 +0000

An endpoint’s purpose is to buffer messages for a consuming application. Some applications require all messages, whereas other applications require this guarantee only while they are connected. Solace supports both functionalities with durable and non-durable endpoints. In this post (and this video) I’ll explain how durability affects endpoints and their contents.

Introduction to Solace Endpoints

Durable Endpoints

A durable endpoint is one that stays on the Solace broker until it is explicitly deleted. This endpoint can be created by an administrator, or dynamically created by an application. Durable endpoints are most often used when consuming applications require all messages including those received by the event broker when the application is disconnected.

As an example, imagine an order processing application. A consuming application must receive all order events to ensure each one is processed; any missed events could mean a loss in revenue. A durable endpoint would be used to ensure the consuming application receives all order events, even if they disconnect.

Non-durable Endpoints

A non-durable endpoint, also known as a temporary endpoint, has a shorter lifecycle and can only be created by an application. The endpoint has a lifespan of the client that created it, with an additional 60 seconds in case of unexpected disconnect. The 60 seconds provides the client with some time to reconnect to the endpoint before it and its contents are deleted from the Solace broker.

An example use case with non-durable endpoints could be an online search for flights. While connected to the system, a consumer would want to see all the available flights at that time. Should they disconnect, they would only want the latest search results and no stale results from a previous search. A non-durable endpoint could be used to buffer these search results while ensuring old results from previous searches are not present.

Permissions and Access

Message storage is a valuable resource on the event broker and administrators may want to control what applications have access to. Through the client-profile object, an administrator can separately control whether an application is able to dynamically create its own durable or non-durable endpoints, and how many it is able to create.

Endpoints also have their own permissions to control which applications can consume from them, modify them, and remove them. These permissions are set when the endpoint is initially created. If a client application creates an endpoint, it is automatically the owner of that endpoint and has full access to it.

It is also important to note that queues created by administrators cannot be removed by client applications, regardless of the permissions set on that endpoint.

Durable vs Non-Durable Endpoints

A durable endpoint can be created and deleted by administrators or applications; if created by an administrator, an application cannot delete the endpoint. Durable endpoints persist with a high availability (HA) failover and with a data replication (DR) failover. Non-durable endpoints can only be provisioned by applications and will remain on the broker if the client is connected, plus an additional 60 seconds for unexpected disconnects. Non-durable endpoints persist over HA failovers, however, due to the manual intervention required do not persist over DR failovers.

Durable endpoints can support multiple consumers, dependent on further configurations of that endpoint. Non-durable endpoints only support a single consumer, and the lifespan of that endpoint is dependent on that consumer.

The name for durable endpoints must be defined by the administrator or application that provisions it, while non-durable endpoints also provide automatically generated names.

Which durability should you use?

Your endpoint durability will relate exactly to the quality of service required by the consuming application. If your application requires all messages even when a disconnect occurs, a durable endpoint should be used. If your application can tolerate loss, or only requires messages while it is connected, a non-durable endpoint can be used.

Conclusion

I hope this post has helped you understand the concept of endpoint durability, and how durability affects the two types of endpoints that Solace supports, along with their contents. In case you missed the link above, I’ve embedded below a video version of the same content. If you found this post useful, you can visit the endpoints section of our docs and our PubSub+ for Developers page for more information. You can also check out some sample code on Github.

If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.

The post Understanding Solace Endpoints: Durable vs. Non-Durable appeared first on Solace.

Understanding Solace Endpoints: Queues vs. Topic Endpoints

Leah Robert — Mon, 03 Feb 2020 21:23:29 +0000

One of the most frequent questions customers ask me is “What is the difference between a queue vs. a topic endpoint?”. While both queues and topic endpoints persist messages, it’s important to understand what they are, how they’re different, and when each one should be used.

Introduction to Solace Endpoints

Solace endpoints are objects created on the event broker to persist messages. There are two types of endpoints: queue endpoints (usually just called queues) and topic endpoints.

Topic Endpoints vs Topics

Before we talk about queues vs. topic endpoints, it’s important to note that a topic endpoint is not the same thing as a topic. Topics are a message property the event broker uses to route messages to their destination, and they aren’t administratively configured on the event broker. Topic endpoints, on the other hand, are objects that define the storage of messages for a consuming application, and they do need to be provisioned on the event broker. Topic endpoints are more closely related to queues than to topics, as confusing as that can seem at first.

Common Characteristics of All Endpoints

Before we compare queues and topic endpoints, let’s take a high-level look at endpoints in general:

Topic Subscriptions : A consuming application uses subscriptions to route messages towards it. Solace endpoints can have topic subscriptions applied to attract messages to the endpoint where a consuming application receives the messages from.
Selectors: A conditional statement applied to an endpoint by a consuming application to filter messages by their header and user properties.
Queue Browsing: A consuming applications’ ability to read messages from a queue without removing them from the queue.

Queue vs. Topic Endpoints

Sending by Name: A producing application has the option to send a message directly to a queue by referencing that queue by its name in the message properties. A producing application cannot, however, reference topic endpoints by name, and therefore only persist messages routed to the topic subscription applied to the topic endpoint.
Support for Multiple Topic Subscriptions: Queues support multiple topic subscriptions. This allows for topic aggregation to a single consuming application. Topic endpoints support a single subscription; should that subscription change, all messages persisted to the topic endpoint are deleted. Messages persisted in queues are unaffected by subscription changes.
Application of Selectors: Selectors can be applied to either type of endpoint to apply conditional logic, but the two endpoints differ in when the conditional is processed. With queues, selectors are processed at egress, and with topic endpoints they are processed on ingress. This means that queues persist every message even if they don’t match the selector, while with topic endpoints messages are only persisted if they match both the topic subscription and the selector.
Support for Multiple Consumers: Queues support multiple consumers, providing a fault tolerant option should a consuming application disconnect from the queue. Topic endpoints support a single consumer, matching the functionality of a JMS durable subscription.
Ability to Read Without Removal: Finally, a queue can be read from without removing messages, whereas topic endpoints require the removal of messages to be read.

Which endpoint should you use?

With all of that said, lets look at the question of queue vs. topic. Queues are used more often because of their support for more subscriptions, and more consumers, and the ability to read without removal which is very handy for troubleshooting and special processing.

Topic endpoints may be better if you want to apply selector processing sooner to filter messages and not necessarily save them to the endpoint. Also, note that topic endpoints were originally created to support durable subscriptions in JMS, and is the only option for JMS durable subscribers.

I hope this post has helped you understand the matter of queue vs topic endpoint. If you found this post useful, visit the endpoints section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.

The post Understanding Solace Endpoints: Queues vs. Topic Endpoints appeared first on Solace.