Für the concrete scenario at hand you could have the low prio Update events carry a If-older-than field so you would not dequeue them but let the processor discard them. Much easier than have concurrent updates (however only efficient for certain traffic patterns)
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: osgi-dev-boun...@mail.osgi.org im Auftrag von Alain Picard via osgi-dev <osgi-dev@mail.osgi.org> Gesendet: Mittwoch, Februar 27, 2019 12:50 PM An: OSGi Developer Mail List Betreff: Re: [osgi-dev] Removing queued events in Push Steams Anyone has any insight here? Alain On Tue, Feb 5, 2019 at 1:28 PM Alain Picard <pic...@castortech.com<mailto:pic...@castortech.com>> wrote: Hi, We have cases where we need to process events with different priorities, and such priority can change after the initial event having been queued, but not yet processed. For example, when there is an event that some content has changed, we subscribe to this event and based on some conditions this might trigger the need to update some diagrams in our case. This is considered a "background priority" event, since we simply want to get it updated when we have some cycles so as not being stuck doing it whenever someone requests such diagram to view/edit it. We also have events when someone for example requests to open such a diagram, where we need to determine if it is up to date, and if it needs to be updated, to get this pushed and processed as quickly as possible, as the user is waiting. So far we have setup 2 different push streams to support this. The issue here is that while this is high-priority event comes in, we need to make sure that we can cancel any similar queued events from the low priority stream, and possibly let it proceed if it is already being processed. What is the best approach here ? Are we on the right track to start with? Thanks Alain
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
