NonDurable TopicEndpoint Creation with Connection Factory for JMS API

SasikumarSP

Hi All,

JMS Connection Factories can be created for each msg-VPN in Solace. This can be used to maintain/configure JMS connection properties administratively instead of API code.

JMS applications can listen to Solace topic directly for both guaranteed and for non-guaranteed message delivery.

When a JMS connection subscribe to topic with "Direct Transport" enabled Connection Factory (CF) then its non-guaranteed message delivery.

The nonDurable TopicEndpoint (temporary TopicEndpoints) get created if JMS application listen to topic with connection factory Direct Transport is disabled. Message get delivery till the subscriber is online.

The best practice is to create two connection factories (one with direct transport enabled and another one with disabled) for each msg-VPNs.

marc

Thanks for sharing @SasikumarSP!

I just want to clarify to others that you're referring to the "Direct Transport for Non-persistent messages" option on JMS Connection Factories and that it only affects Non-persistent messages

Tamimi

Thanks for contributing to the tips and tricks @SasikumarSP !

SasikumarSP

@marc

As per my understanding, this can be used for persistent messages too but we need to be aware that nonDurable TEs are temporary and messages get lost if the subscriber disconnect from solace.

The advantage of using this nonDurable TEs to get guaranteed delivery of messages and deduplication as long as the subscriber is online.

Thanks,

marc

Hi @SasikumarSP,

Sorry, I probably should have provided more info in my explanation. To clarify, the "Direct Transport for Non-persistent messages" option will not affect apps that create a Durable subscription in JMS or publish persistent messages.

You are correct that a JMS app using a Non-Durable TE can receive both messages published as non-persistent or persistent.

azakovorotny

I've just started with Solace and many terms are confusing. From the AMQ background, say, I publish events to a Topic and a number of currently active consumers subscribed to the topic each need to receive a copy of the message while active. There is no need to persist those messages, neither the subscribers are interested in messages posted when subscriber was offline.

That was super easy with AMQ using JMS API. However, I cannot quite match this to the Solace queue/topic/endpoint model.

Is having a queue inevitable in Solace? In my understanding a queue is only required to "track the state", perhaps for replication and failover purposes too. But I only need a non-durable, non-persistent topic. If there are no active subscribers - all messages are just discarded, if there is a number of active subscribers - they all get their copy of a message. It is just a "fire-and-forget".

How can it be mapped to the Solace terms?

marc

Hi @azakovorotny,

Welcome to the Solace Community!

You definitely don't have to use Queue or Topic Endpoints. Those are only for guaranteed messaging use cases. "Direct Messaging" is our non-guaranteed class of service in which apps just publish and subscribe to topics (Note - not a Topic Endpoint; there is a difference which I agree is confusing).

And you can even do this with JMS as Solace has a JMS API, e.g:

* JMS TopicPublisher: https://github.com/SolaceSamples/solace-samples-jms/blob/master/src/main/java/com/solace/samples/TopicPublisher.java

* JMS TopicSubscriber: https://github.com/SolaceSamples/solace-samples-jms/blob/master/src/main/java/com/solace/samples/TopicSubscriber.java

You can read more about our transport modes here: https://docs.solace.com/API/Solace-JMS-API/Message-Transport-Modes.htm

I tried to keep this short since it's on another thread, but if you have more questions feel free to create another thread :)

Hope that helps!