Normally the creating of the subscription group is not done in your general executable code. Instead it is normally done as a step during an install or as an admin task when setting things up. You should assume the subscription exists in your code.
I’m in a situation where I can benefit from creating/destroying subscription groups at any time during the execution of my app, depending on the presence of some user input. So I’m wondering why the comment above advises against that. Maybe it is the fact that admin privilege is required to do so? Is there any other reason why?
Can you explain more your use case? You can obviously create/destroy them
on the fly but it would be unusual.
Users can create “campaigns” that are a bunch of rules that basically say “if this happens, do that”. These rulesets are required to be able to apply retroactively, i.e., “react” to events that occurred before the ruleset itself was created.
So I’m thinking that each campaign runs its own subscription group. I’d create a subscription for every new campaign defined in the system and destroy the sub when that campaign ends some time later. With this, I get the ability to balance the load across any number of nodes while “running” every campaign on all nodes. If I instead opt for each campaign to run on a single node with a client side sub, I’d have to bear the pain to come up a with an effective way to balance the number of campaigns running on each node.
Hope this makes sense.
Why not just create one subscription group and route all the campaign events to it?
Each campaign needs to be aware of all events since the beginning of the recorded history - the “retroactive” requirement. With one subscription group, each new subscriber gets only the as-yet-unacknowledged events, no?