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 <osgi-dev@mail.osgi.org> > 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 > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
