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
