jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI observation: EventFilter lifecycle
Date Fri, 02 Nov 2007 14:00:42 GMT
Marcel Reutegger wrote:
> Julian Reschke wrote:
>> Question: do we expect many cases in which a client stops listening 
>> for events, but keeps the JCR session open? In this case it might be 
>> good if we could indicate that an EventFilter is not going to be used 
>> anymore, for instance using a dispose() method.
> 
> this is actually only half the story: julian noticed that there may be 
> situations where events are lost. one scenario is available here: 
> http://people.apache.org/~mreutegg/spi-event/problem.png
> (for simplicity I omitted save calls)

Actually I already started to compose a mail about this one, when it 
occurred to me that a solution may be trivial...

> the sequence of calls on the jcr api is the following:
> - add an event listener EL with a filter EF1
> - set a property on a node, which is in scope of EF1
> - change the filter for EL to EF2
> - set a property on a node, which is in scope of EF2 but not EF1
> 
> with the current design it is very likely that the event for the second 
> change is blocked by EF1, which is still in use, even though the client 
> changed the filter to EF2. The reason for this is the way how the 
> polling is designed (in SPI interfaces) and implemented in JCR2SPI. 
> There is a polling thread in JCR2SPI, which blocks until an event occurs 
> or a timeout is reached. The poll call is done with the latest available 
> event filter on the client.
> 
> julian and I briefly discussed two solutions (or workarounds, because I 
> think we should rather re-design the SPI eventing):
> 
> 1) block the client thread on the second addEventListener call and 
> return only when the polling thread times out and returns to the client. 
> see: http://people.apache.org/~mreutegg/spi-event/solution1.png
> 
> 2) interrupt the poll thread and force it to call getEvents with the new 
> event filter. see: 
> http://people.apache.org/~mreutegg/spi-event/solution2.png
 > ...

How about:

3) define that creating a new EventFilter should have the side effect to 
terminating all current calls to getEvents()?

There's probably still a chance to get the timing wrong, but then, it 
seems like the simplest thing that can work to me.

BR, Julian

Mime
View raw message