Re: [osgi-dev] Removing queued events in Push Steams

[Bernd Eckenfels via osgi-dev]

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 

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 
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

Re: [osgi-dev] Removing queued events in Push Steams

[Tim Ward via osgi-dev]

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  
> 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 > > wrote:
>> 
>> 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 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
> 
> ___
> 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

Re: [osgi-dev] Removing queued events in Push Steams

[Peter Kriens via osgi-dev]

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  
> wrote:
> 
> 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 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

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Removing queued events in Push Steams

[Alain Picard via osgi-dev]

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 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