Stream Subscription Multiplicity #202
Conversation
…id. - incomplete, does not compile
…e add Unsubscribe call to handle.
…s equality check. Style change only.
…final pass and didn't wait final if it got to end of loop.
Renamed SubscriptionMultiplicityTests to SubscriptionMultiplicityTestRunner and included it into test using composition rather than inheritance.
|
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. |
Made IStreamProviderImpl public so stream providers can be developed externally.
|
PR updated. |
|
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.