Progress Sonic 8.0 ESB Configuration and Management Guide

Chapter 3: ESB Endpoints and Connections
For detailed information on implementing durable subscriptions, see the “Publish and
Subscribe Messaging” chapter in the Progress SonicMQ Application Programming
Guide.
The following example illustrates Sonic ESB’s naming convention for this feature:
● A service named Service1 is deployed in MFContainer1 and MFContainer2.
Service1 has:
■ Two listeners in MFContainer1
■ One listener in MFContainer2
● The subscription name is myDurableSub
● The topic that is subscribed to myDurableSub is T1
● These services share a subscription to the topic name [[Service1]]T1 (concurrent
durable subscriptions in Sonic ESB have shared subscriptions enabled by default)
● The dynamically generated subscription names are:
■ MFContainer1:Service1:1:myDurableSub
■ MFContainer1:Service1:2:myDurableSub
■ MFContainer2:Service1:1:myDurableSub
Three durable subscriptions are created. Distribution to the durable subscriptions is based
on factors including the number of active clients and flow control status.
Each listener on a single service accesses the same, shared durable subscription, thus
improving the throughput of a deployed service instance by enabling concurrent message
processing. When a listener is eliminated, its durable subscription is not automatically
eliminated, which causes that durable subscription to remain inactive until the subscriber
returns .
Note In conjunction with the shared subscription functionality, messages for a shared durable
subscription that might be stranded in these now-defunct subscriptions are re-allocated
to whichever shared subscribers are connected, whether durable or nondurable.
There is an advantage to using only durable subscribers in a shared subscription as a
failure of a regular subscriber without acknowledgement of a delivered message has no
mechanism for restarting and re-allocating the indoubt message.
94 Progress Sonic ESB Configuration and Management Guide 8.0