Cost of JCSMPSession

radekm

Hi,
I'm creating an app which reads messages from multiple Solace topics. Different parts of my app need to read from different topics. And I wonder

(1) if I should create only one JCSMPSession subscribe to all topics and then dispatch messages to different parts of my application
(2) or create JCSMPSession in each part of my application?

Variant (2) seems better for implementation since it allows to make different parts of my application more independent. On the other hand I would need 50-100 connected JCSMPSessions. Isn't that too much? Or is it really cheap?

Thanks

[Deleted User]

I don't come from a Java background, so take what I say with a grain of salt and wait for some others to chime in, but typically I build a dispatcher sort of class for any applications that need to maintain a multi topic subscription list. This class does exactly what you described in (1), it dispatches messages from the onMessage message handler to different parts of the application.

If you want the different parts of your application to be more independent, have you considered breaking them out into separate microservices? It all depends how many of these services you plan on running, but I'd be weary of embracing N connections per application from an architecture standpoint.

radekm

Makes sense.
In the meantime I looked at .NET API and discovered Topic Dispatch which would make (1) a lot easier to implement. But unfortunately we're using mostly Java/Kotlin via JCSMP API which according to the documentation (https://docs.solace.com/Solace-PubSub-Messaging-APIs/API-Developer-Guide/Receiving-Direct-Message.htm) doesn't support Topic Dispatch. But in API Reference I found interface MessageDispatcher (https://docs.solace.com/API-Developer-Online-Ref-Documentation/jms/com/solacesystems/jcsmp/impl/MessageDispatcher.html) so I have hope that it will be available soon

marc

Hi @radekm,
I agree with @andrew_j_roberts that it is recommended to re-use the JCSMPSession when possible. It comes with not only in app overhead but is actually connecting out to the broker and uses broker resources. This docs page is super useful when it comes to understand what is going on between the broker and your app. Note that with JCSMP you're using SMF.

JCSMP with manual topic dispatch will definitely work ( or breaking your app into multiple microservices for simplification ) but if you're using Java w/ Spring another option could be to also leverage Spring's JMS capabilities such as the @JMSListener annotation which allows you to specify a destination per method. There is an example in this thread.

-Marc

Aaron

Definitely don't create multiple JCSMPSessions for each topic... each of those is essentially a TCP connection, and the broker tracks and limits how many connections (aka clients) are allowed to be connected. That is: sessions (connections) are not that "cheap". That, and one connection can do 100,000 msgs/s no problem. So much better to implemented some logic / dispatch yourself..! Most of my onRecieve() methods are giant if/else blocks.