Hi - I’m afraid that I’m out on vacation this week, so I can’t put quite as
much into my reply as I normally would.
It sounds like you have a PushStream pipeline with multiple buffered stages.
This isn’t a problem, and can be a good thing, but as you’re noticing it is
leading to the following
://bernd.eckenfels.net
Von: osgi-dev-boun...@mail.osgi.org im Auftrag von Alain Picard via osgi-dev
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
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 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
Anyone has any insight here?
Alain
On Tue, Feb 5, 2019 at 1:28 PM Alain Picard 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
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
