Another option would be for you to take control of the queuing using a QueuePolicy. That would enable you to insert work at the head of the buffer (or at least higher up) if it was more important. You could also remove some of the entries if they are invalidated by the higher priority insert.
I await the results of your research with interest :) Best Regards, Tim > On 27 Feb 2019, at 12:45, Peter Kriens via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > I probably would use a (static?) priority set with a weak reference to the > event object. (Or some key that uniquely identifies that object). The > processor can then consult this set to see if the event has higher priority. > A weak reference is needed to make sure that no events remain in this > priority set without locking. > > PK > >> On 27 Feb 2019, at 12:49, Alain Picard via osgi-dev <osgi-dev@mail.osgi.org >> <mailto:osgi-dev@mail.osgi.org>> wrote: >> >> 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 <mailto: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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
