I think more doc is needed to inform users about the characteristics of the current impl:
Clarify there's no buffering/memory for tuples added to a topic: a published tuple is delivered only to current subscribers. The current wording focuses only on the no-subscribers case.
Must manually add a PublishSubscribeService to a provider instance to use this service. An example code fragment in the class would be beneficial.
The ProviderPubSub impl only works between topologies from the same provider instance
A publishing stream is isolated from its subscribers, and the subscribers from each other, via an implicit PlumbingStreams.isolate() on each subscribing stream. Users may want/need to manually insert a PlumbingStreams.pressureReliever() on subscriber streams to avoid excessive memory resource use from subscribers that can't keep up with the tuple production rate.
A sample demonstrating pub/sub use would be beneficial.
generally +1 on all of this!
I think more doc is needed to inform users about the characteristics of the current impl:
PublishSubscribeService
to a provider instance to use this service. An example code fragment in the class would be beneficial.ProviderPubSub
impl only works between topologies from the same provider instancePlumbingStreams.isolate()
on each subscribing stream. Users may want/need to manually insert aPlumbingStreams.pressureReliever()
on subscriber streams to avoid excessive memory resource use from subscribers that can't keep up with the tuple production rate.A sample demonstrating pub/sub use would be beneficial.