Anyone has any insight here? Alain On Tue, Feb 5, 2019 at 1:28 PM Alain Picard <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
