I
guess modifying an existing Subscription makes life simpler
by guaranteeing atomicity, and by avoiding creating
entirely new subscription when you really wanted to make a
certain small change.
The
concerns you raised below seem to be relevant only if one were to take the
alternative approach of canceling a Subscription and creating a new one , which
does not seem to be necessary. Perhaps I am missing
something!
On a
side note -- If we had a property such as EffectiveFrom on the Subscription, it would
have been possible to send two separate messages for Subscribe and Cancel
(actually SetTerminationTime) and still achieve atomicity (assuming that there
is sufficient time window available for the Producer to receive and process both
Subscribe and Cancel messages before the new subscription becomes effective). I
am not suggesting that we need to work on such an alternative protocol for
modifying Subscriptions. It just struck to me as a generally valid use case for
having a property such as - EffectiveFrom.
Thanks,
Sanjay
As far as I can tell, and correct me if I'm
wrong, the main reason to allow a subscription to be modified, as opposed to
closing it out and creating a new one, is atomicity. The clearest
example of this I can see is useNotify (though I'm at a loss for a use
case). If I change useNotify, then I know that I will receive every
message produced exactly once, and at some unspecified time in the future the
consumer will start seeing messages in the other format. On the other
hand, if I first create a new subscription and then delete the old, the
consumer may get some set of messages twice, once in the old format and once
in the new.
We need to be careful about simultaneity here. About
the only things we can count are that a message arrives after it is sent, and
that for a given connection, messages arrive in the order they are sent.
But if two different sources send to the same sink, the exact interleaving of
arrivals is undefined. In this context I am further assuming that if the
NotificationProducer receives (Subscribe new, Cancel old), any notifications
produced between these events will go to both subscribers. But this is
not certain, and we need to nail this down.
Now let's consider the
various properties that can be set:
- ConsumerReference: Atomicity means that every notification sent
(assuming no other properties are changed) will go to either the new or the
old consumer, but not both.
- TopicExpression: Every notification sent to the intersection of the two
topic sets will arrive, regardless of when the switch actually takes
effect. I don't believe there are any guarantees for topics outside
the intersection.
- UseNotify: See above.
- Precondition/Selector. Again, atomicity only matters for the
intersection.
- SubscriptionPolicy: This may depend on the actual policies involved, but
the situation should be essentially similar to useNotify.
So there
are at least two questions here: Can or should we require any guarantees
for the case where the same producer hears a new subscription creation and
then an old one canceled? In other words, does arrival time at the
producer matter in the context of notifications sent to a consumer?
If
so, how important are the atomicity guarantees for setting properties?
The worst side effect seems to be the possibility of duplicate messages.
And if guaranteeing ordering of subscriptions/cancellations is not feasible,
how feasible are the atomicity guarantees for setting properties?
My
gut feeling right now is that significantly changing a subscription's
properties in-flight is tantamount to canceling it and creating a new one, and
it would be nice to reflect that without losing useful atomicity
properties. In any case, the key semantic to look at is the ordering of
events in an inherently loosely-ordered system.
Hope that makes
sense.
|