jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: SPI observation: EventFilter lifecycle
Date Fri, 02 Nov 2007 13:23:16 GMT
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)

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

both approaches have drawbacks. 1) will block the calling thread O(timeout). The 
current JCR2SPI implementation has a fixed poll timeout of 3 seconds. if client 
code regularly adds and removes event listeners, then the application becomes 
unusable. 2) does not work with the sun RMI implementation. There is a 
workaround for this issue: https://interruptiblermi.dev.java.net/

I'm working on a proposal that introduces a Subscription interface to the SPI, 
which should solve the above issue.

here's a sneak preview: http://people.apache.org/~mreutegg/spi-event/proposal.png

regards
  marcel

Mime
View raw message