Re: SPI observation: EventFilter lifecycle
Marcel Reutegger wrote: ... 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 ... OK, as far as I understand this, we pass a Subscription object into getEvents(), and EventFilters are attached to the subscription? Works for me. Go ahead! Best regards, Julian
Re: SPI observation: EventFilter lifecycle
Jukka Zitting wrote: Hi, On 11/1/07, Julian Reschke [EMAIL PROTECTED] wrote: Proposal: document that getEvents only needs to accept EventFilter objects created by the same SPI implementation for the same SessionInfo (this reflects reality in JCR2SPI) +1 There's no guarantee that a remote implementation can deserialize foreign EventFilters. That's already part of the Javadoc. The change I want to make is that it's also bound to a specific SessionInfo. Proposal: remove special case in getEvents for EventFilter array being null. +1 One can achieve the same result using a catchall EventFilter. And it seems JCR2SPI is doing that already. These changes will allow the SPI implementation to early filter internal events, even before getEvents() gets called. Nice. 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. I guess that's a relatively rare use case, so I'd just ignore it for simplicity. BR, Jukka Zitting Thanks for the feedback, Julian
Re: SPI observation: EventFilter lifecycle
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
Re: SPI observation: EventFilter lifecycle
Hi, On 11/1/07, Julian Reschke [EMAIL PROTECTED] wrote: Proposal: document that getEvents only needs to accept EventFilter objects created by the same SPI implementation for the same SessionInfo (this reflects reality in JCR2SPI) +1 There's no guarantee that a remote implementation can deserialize foreign EventFilters. Proposal: remove special case in getEvents for EventFilter array being null. +1 One can achieve the same result using a catchall EventFilter. These changes will allow the SPI implementation to early filter internal events, even before getEvents() gets called. Nice. 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. I guess that's a relatively rare use case, so I'd just ignore it for simplicity. BR, Jukka Zitting
