Differences in Durable and Non durable subscriptions of a topic endpoint

rdesoju

Hi,
I observed a difference in message delivery pattern with the below setup:
1. a topic endpoint (Non-Exclusive)
2. Two Non Durable Subscribers
3. Two Durable Subscribers
(note: each subscriber was given a unique name so that there is no connection conflict)

When Producer published messages, Two non-durable subscribers received all copies of messages. However, messages are delivered alternatively to durable subscribers and hence each durable subscriber received half of the messages. Client program had an id (custom sequence number generated inside producer) in each message. So, DurableSubscriber1 received 1,3,5,7,9....and DurableSubscriber2 received 2,4,6,8 and so on.

Two questions:
1. Is this an expected behavior?
2. Is there any configuration setting using which we can make all DurableSubscribers receive all messages?
Please suggest.

Thanks,
Raghu

marc

Hi @rdesoju,
Let's approach this problem by taking a quick step back. In order to really achieve the benefits that an event-driven architecture promises we need to make sure we're able to decouple our publishers from our subscribers. The way PubSub+ Event Brokers work allow you to easily do this. As a publisher you publish your messages/events to topic(s). The topic an event is published to is really just a label in the message header (it's not an endpoint!). This label will then be used by the Event Broker to decide which subscribers to route the event to. So do not think of a topic on the publishing side as where you are publishing to but more so think of it as a way to provide metadata that describes what you are publishing. This what is useful for your subscribers to filter the events that they want to receive. A few examples here:

So now that we have events being published to a topic that describes what we are publishing the event broker can now use that topic metadata to decide which application(s) receive those events. This includes whether an event is sent to 0, 1 or fanned out to many subscribers (like your use case). In order to know where to route the events the subscribers must tell the event broker what events they are interested in. This is done by specifying topic subscriptions and there are a few different ways to do this depending on your requirements. The two most common options that I see are as follows:

1). It's okay if I miss messages during network outages or if my app is down. Then my app is fine with consuming from the non-persistent event stream and will make my topic subscriptions directly
2). It's NOT okay if I miss messages when issues occur. Then my app needs to consume from the persistent event stream and will bind to a durable endpoint to consume events. The durable endpoint exists on the broker, is configured with topic subscriptions to attract events based on their topic metadata, and will persist events if my apps goes down or offline. So each endpoint captures

Hopefully that background information around the decoupling of publishers from subscribers helps with the answers below...
So let me answer your two questions:

1). This is indeed expected! To quote from our docs:

For an exclusive topic endpoint, only one client can bind and receive messages; if other clients attempt to bind, they will be rejected. An exclusive durable topic endpoint always delivers messages in the order they are received. For non-exclusive durable topic endpoints, multiple consumers can bind and each is serviced in round‑robin fashion.

2). If you're using Durable Subscribers then I assume your subscribers fall into the category of number 2 above. You don't want to lose messages when your app(s) go offline. In order to do this you need a durable endpoint for each copy of the event stream that will be delivered to your apps so the broker can individually manage the events after fan out. As @amackenzie suggested the most common way to do this is to create a queue endpoint for each app. A queue endpoint allows you to have multiple topic subscriptions on one endpoint and also the ability to have multiple instances of an application for round-robin (w/ a non-exclusive queue) or high availability primary/secondary/tertiary (w/ an exclusive queue).

rdesoju

Hi @marc ,
Thank you very much for the great explanation !
I have below questions after going through the information:
1. Fan out with multiple durable subscriptions does not work without having the 'Queues' (in the middle) subscribe to the topic. Correct?
2. Both durable and non-durable subscriptions does not show the same behavior. In case of non-durable subscriptions, all subscribers are able to receive all messages. However, in case of durable subscription, subscribers are receiving only sub set of messages in a round robin fashion as mentioned. May I know what is the reasoning behind treating these two subscription models differently?

Thanks,
Raghu

marc

Hi @rdesoju,
1. Correct. You need a durable endpoint for each copy of the event stream that you want delivered. I highly recommend reading about how Solace Event Streaming works on this docs page. It's great information and I personally revisit it a lot to as a refresher too https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm
2. The reason this is happening is because the persistent subscribers are actually binding to the same durable endpoint which is receiving one copy of the persistent event-stream. And then from that durable endpoint (which is non-exclusive) the messages are being shared across the apps bound to it. The opposite is true for your non-durable subscriptions. They are not using durable endpoints and are each getting their own copy of the event stream.

amackenzie

Hi,
1. This is intended behavior
2. Create a queue for each consumer and have them all attract the same topic - all queues will have the same messages because they are attracting messages using the same subscriptions (assuming that's how they are configured). Each consumer would bind to their own queue to get their messages. This also means that, since each consumer acknowledges its own messages, that the various consumers don't all have to be online and processing messages at the same pace like they do when using non-persistent/direct messaging.

It's unclear which API you are using for your use case. There is some JMS terminology there but also some Solace-specific terms. Can you elaborate on this?

There are some good sections of our docs that talk about these topics like:

• Persistent vs. Durable - https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm#Persiste
• non-persistent concepts and map - https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm#Non-Dura2
• persistent concepts and map - https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm#Durable2

rdesoju

some issue with the page.

marc

Hi @rdesoju,
Let's approach this problem by taking a quick step back. In order to really achieve the benefits that an event-driven architecture promises we need to make sure we're able to decouple our publishers from our subscribers. The way PubSub+ Event Brokers work allow you to easily do this. As a publisher you publish your messages/events to topic(s). The topic an event is published to is really just a label in the message header (it's not an endpoint!). This label will then be used by the Event Broker to decide which subscribers to route the event to. So do not think of a topic on the publishing side as where you are publishing to but more so think of it as a way to provide metadata that describes what you are publishing. This what is useful for your subscribers to filter the events that they want to receive. A few examples here:

So now that we have events being published to a topic that describes what we are publishing the event broker can now use that topic metadata to decide which application(s) receive those events. This includes whether an event is sent to 0, 1 or fanned out to many subscribers (like your use case). In order to know where to route the events the subscribers must tell the event broker what events they are interested in. This is done by specifying topic subscriptions and there are a few different ways to do this depending on your requirements. The two most common options that I see are as follows:

1). It's okay if I miss messages during network outages or if my app is down. Then my app is fine with consuming from the non-persistent event stream and will make my topic subscriptions directly
2). It's NOT okay if I miss messages when issues occur. Then my app needs to consume from the persistent event stream and will bind to a durable endpoint to consume events. The durable endpoint exists on the broker, is configured with topic subscriptions to attract events based on their topic metadata, and will persist events if my apps goes down or offline. So each endpoint captures

Hopefully that background information around the decoupling of publishers from subscribers helps with the answers below...
So let me answer your two questions:

1). This is indeed expected! To quote from our docs:

For an exclusive topic endpoint, only one client can bind and receive messages; if other clients attempt to bind, they will be rejected. An exclusive durable topic endpoint always delivers messages in the order they are received. For non-exclusive durable topic endpoints, multiple consumers can bind and each is serviced in round‑robin fashion.

2). If you're using Durable Subscribers then I assume your subscribers fall into the category of number 2 above. You don't want to lose messages when your app(s) go offline. In order to do this you need a durable endpoint for each copy of the event stream that will be delivered to your apps so the broker can individually manage the events after fan out. As @amackenzie suggested the most common way to do this is to create a queue endpoint for each app. A queue endpoint allows you to have multiple topic subscriptions on one endpoint and also the ability to have multiple instances of an application for round-robin (w/ a non-exclusive queue) or high availability primary/secondary/tertiary (w/ an exclusive queue).

rdesoju

Hi @marc ,
Thank you very much for the great explanation !
I have below questions after going through the information:
1. Fan out with multiple durable subscriptions does not work without having the 'Queues' (in the middle) subscribe to the topic. Correct?
2. Both durable and non-durable subscriptions does not show the same behavior. In case of non-durable subscriptions, all subscribers are able to receive all messages. However, in case of durable subscription, subscribers are receiving only sub set of messages in a round robin fashion as mentioned. May I know what is the reasoning behind treating these two subscription models differently?

Thanks,
Raghu

marc

Hi @rdesoju,
1. Correct. You need a durable endpoint for each copy of the event stream that you want delivered. I highly recommend reading about how Solace Event Streaming works on this docs page. It's great information and I personally revisit it a lot to as a refresher too https://docs.solace.com/PubSub-ConceptMaps/Event-Stream-Maps.htm
2. The reason this is happening is because the persistent subscribers are actually binding to the same durable endpoint which is receiving one copy of the persistent event-stream. And then from that durable endpoint (which is non-exclusive) the messages are being shared across the apps bound to it. The opposite is true for your non-durable subscriptions. They are not using durable endpoints and are each getting their own copy of the event stream.

rdesoju

Thank you again for detailed insight into the behavior !!

marc

No problem
Happy eventing!