The connection pooling feature of ENS enables a pool of subscribers to receive notifications from a single event reference. For every event, ENS chooses one subscriber from the pool to send the notification to. Thus, only one subscriber in the pool receives the notification. The ENS server balances sending of notifications among the subscribers. This enables the client to have a pool of subscribers that work together to receive all notifications from a single event reference.
For example, if notifications are being published to the event reference enp://127.0.0.1/store, a subscriber will normally subscribe to this event reference to receive notifications. To have a pool of subscribers receive all the notifications to this event reference, each subscriber in the pool only needs to subscribe to the event reference enp+pool://127.0.0.1/store instead. The ENS server chooses one subscriber from the pool to send the notification to.
The publisher still sends notifications to the simple event reference, in the example above enp://127.0.0.1/store, that is, the publisher has no knowledge of the subscriber pool.
Connection pooling can support multiple pools of subscribers. That is, you can have two pools of subscribers, each pool receiving all the notifications from the event reference. The syntax of the event reference for the subscriber is:
where poolid is a string using only base64 alphabet. (See RFC1521, Table 1, for what the base64 alphabet contains.) So, for example, to have two pools of subscribers to the event reference enp://127.0.0.1/store, each pool could subscribe to the following event references:
enp+pool.1://127.0.0.1/store– for first pool of subscribers enp+pool.2://127.0.0.1/store– for second pool of subscribers