Progress Sonic ESB Configuration and Management Guide

Using Shared Subscriptions to Topics
Evaluating Endpoint Requirements on JMS Destinations
With topic subscriptions there can be cases where one application acting as a topic
subscriber cannot process messages as fast as messages are being published. This leads to
a bottleneck, where the subscribing application falls farther and farther behind.
You can establish groups of topic subscribers that share subscriptions to allocate the
message load among them. Within these groups, each message is delivered to, and
consumed by, only one member of the group. These group members can be located on
dispersed computers over diverse JMS connections. The implementation is compatible
with clusters of brokers so that the members of a consumer group can connect to different
brokers in a SonicMQ cluster. Regular subscribers, durable subscribers, and participants
in a shared subscription can be active concurrently on a broker.
Sonic ESB prepends the service name to the topic name when defining subscribers within
a group: [[ServiceName]]topicName. When you select a destination for a shared
subscription, Sonic ESB automatically prepends the service name to the topic you select
(if shared subscriptions are enabled for the service, which is the default condition).
For detailed information on implementing shared subscriptions, see the “Publish and
Subscribe Messaging” chapter in the Progress SonicMQ Application Programming
Guide.
Using Concurrent Durable Subscriptions to Topics
You can configure the entry endpoint of a service to define a durable subscription to a
topic. In Sonic ESB, multiple service instances can concurrently process messages sent to
a durable subscription.
Durable subscriptions are created using a unique prefix appended to the subscription
name configured on the JMS endpoint. The unique prefix consists of the management
container name, the name of the ESB service configuration (the service name), and the ID
of the message listener.
The Concurrent Durable Subscription setting on an endpoint is a boolean value:
● When set to False, the number of listeners to is limited to one. Also, only one instance
of the service can be running anywhere in your ESB. This setting is preferred if you
care about guaranteeing order in processing. The effect is similar to setting Exclusive
on a queue.
● When set to True, the default value, multiple containers are allowed to run the service,
and each of those containers can have multiple listeners. This setting is appropriate
when you want to load-balance and scale processing, and are not concerned about
order in processing.
Progress Sonic ESB Configuration and Management Guide 8.5 100