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
