Tim, One thing that I'm unsure about your suggestion. My expectation is that after the "flush error event", I can again accept new published event and process those until I get another case where the cached information is invalidated (i.e. the notification event changes the result set and there is no way to simply update the cache and we have to re-run the query). I am unclear as to how this would happen.
Thanks Alain On Thu, Nov 15, 2018 at 5:52 AM Tim Ward <[email protected]> wrote: > The correct option will depend on what you want to happen. If you use an > endOfStream() or close() operation then you are telling your push stream > that the data has reached a “natural end”. This will cause the promise at > the end of your stream to resolve normally. This may be the right thing in > some cases. > > In the case that you describe I agree that endOfStream() and close() don’t > seem like the correct approach. The data hasn’t reached a natural > conclusion, and in fact the processing so far has been invalidated. This is > the perfect opportunity to send an error event! You can send an Exception > indicating that the result set was not completely processed, and > potentially has been invalidated. The default behaviour of the push stream > will then be to fail the pipeline, however a terminal “forEachEvent” > handler could still choose to do something useful with the information. For > example it might choose to trigger recreation of the stream against the > updated dataset! > > I hope this helps, > > Tim > > > On 15 Nov 2018, at 09:52, Alain Picard via osgi-dev < > [email protected]> wrote: > > > > We are using a push stream to process data change notifications against > a cached result set. Some of those notifications can result in directly > applying updates to the result set, while other will force us to invalidate > the cached result set. > > > > When we do a requery, we want to make sure that any subsequent event > sent to the push stream can be cleared and ignore. Looking at endOfStream() > or close() doesn't seem to be the way to go. Only solution for now is to > switch to a new stream, but wondering if that is the right way to do it. > > > > Regards, > > Alain > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
