In a publish/subscribe model, how do you go about having one class be a listener for more than one topic? It seems logical to just create a TopicSubscriber for each topic you want to listen to. If so, should each TopicSubscriber be created under the same session or different sessions? Is there some rule of thumb to follow or does it not make a difference?

Jerry Smith

Any time that multiple destinations are involved, for example, subscriptions to multiple topics, the preferred approach (in my opinion) is to design a separate class (either inner or conventional, depending on the circumstances) that functions as a message listener for each topic, and then manage each topic in its own session. It's possible, of course, to create multiple TopicSubscriber instances, one per topic, each registered with a common message listener and associated with the same session. In most situations, the latter approach does not scale well and can lead to readability and maintenance problems.

Also, note that sessions are single-threaded contexts. That is, a session uses a single thread of execution for all registered message listeners. Hence, managing multiple topics and listeners within the same session (in effect) attenuates the asynchronous message-handling operations. Suppose that multiple messages arrive at approximately the same time (for example, one per topic for several topics). In this case, all messages except one must wait while the session handles one message notification (executes the registered listener). In this scenario concurrency can be improved by designing listeners with dedicated execution threads. Of course, if there are dependencies among the message-handling operations, for example, common data, the application must accommodate these critical-region issues.

Also, unexpected delays in processing messages, due to serialized message notifications, can have unintended effects for an application. Thus, in many cases, handling each topic subscription in a separate session, simplifies application logic.