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
