Stream Subscription Multiplicity#202
Conversation
…id. - incomplete, does not compile
…subscription_multiplicity
…ription_multiplicity
…e add Unsubscribe call to handle.
…subscription_multiplicity
…subscription_multiplicity
…s equality check. Style change only.
…ription_multiplicity
…ription_multiplicity
…final pass and didn't wait final if it got to end of loop.
…ription_multiplicity
Renamed SubscriptionMultiplicityTests to SubscriptionMultiplicityTestRunner and included it into test using composition rather than inheritance.
…ription_multiplicity
|
I wonder should the parameters always be checked in Orleans codebase except in cases otherwise stated for some reason? There seem to a lot of code that takes parameters and uses them to search, say, some internal collection. That .NET framework code would do checking, but I'm wondering a bit of the side what's the "tone of the codebase", e.g. always check parameters (preconditions) explicitly, comment functions etc. |
|
Fair point to explore. I think hardening the public customer facing APIs would be a good place to start. There were definitely opportunities to improve the code in this PR that I didn’t take. Soon I’ll be making another pass to further address subscription related issues. I’ll opportunistically perform code cleanup during these changes. |
|
I think the parameters should be checked on all public and maybe protected functions. |
|
Please hold this PR. I need to refactor the IStreamProvider and IStreamProviderImpl interfaces to address issues regarding implementation of custom stream providers. This CR did not introduce the problem, but exasperates it. |
…ription_multiplicity
Made IStreamProviderImpl public so stream providers can be developed externally.
|
PR updated. |
…ription_multiplicity
|
Withdrawing pull request to handle a couple edge cases it introduces. |
5 participants
Problem: Currently, a grain can only subscribe once to a given stream. A grain calling SubscribeAsync multiple times on the same stream would reset it's existing pubsub subscription rather than creating a new subscription. This limits certain scenarios, for example when a grain wants to subscribe to a stream simultaneously from different points in time (providing different SequenceTokens).
In the fix, each subscribe call creates it's own subscription to a stream, and multiple subscriptions (even from different points in the stream if recovery token is provided) can be established by a single grain. Each subscription can also be independently unsubscribed, allowing what we call proper Subscription multiplicity.
NOTE: Of course, naturally, a grain that subscribes multiple times to the same stream will receive the events multiple times, once by the observer of each subscription.