After working things through once more, I opted for a simple model where I maintain a global registry of (jcr) event listeners using weak references. Events are queued to be processed later during a request cycle. So, in fact I managed to evade the page eviction problem; at the cost of additional cpu time (pages that have been discarded by the session store will still receive events, even though those will never be processed).
The snags of (de)serialization are handled automatically if listeners are re-registered when the object under observation is deserialized. (i.e. implementing readObject()) This should work independent of session store; any kind of caching scheme is supported this way. It should also work with replication. I'm not sure if this is the solution that Igor suggested, but it sure makes sense to me. Thanks for the help! Cheers, Frank > -----Original Message----- > From: Johan Compagner [mailto:[email protected]] > Sent: 25 January 2009 21:55 > To: [email protected] > Subject: Re: Observation and page (map) eviction > > Maybe if you want listeners then only the session listen to > those? And pages/components when they render pull the changes > out of the session? > > On 25/01/2009, Frank van Lankvelt <[email protected]> wrote: > > But how is a view to know if its model (object) has changed in the > > pull model? One way that I see this working is if views > extract all > > state that they need to do the rendering into a separate > object. This > > object is then recalculated from the model that is used by > the view on > > each request. Is this what you're suggesting? > > > > Of course one should not go about (de)serializing listeners > carelessly. > > I was a bit simplistic in describing what I want there, sorry 'bout > > that. What I'm doing at the moment (with the listener > leak) is that > > the listeners that actually get registered with the object > are stored > > in the session. When they're called (asynchronously), they store > > events in a queue. Then, when a request comes in, this queue is > > emptied by the page that is being rendered; the events are > processed > > by the in-page listeners. This mechanism does depend on the use of > > sticky sessions, as it has to be possible for an external > service to > > invoke the (session) listeners. > > > > The problem is now how to manage the listeners in the > session. They > > only need to be present for the "current" pages in pagemaps, i.e. > > those pages that are shown and that will generate a request > every now > > and then using an ajax-timer. Other pages in the pagemap will be > > redrawn completely when they need to respond to a request, > so there is > > no need for observation for them. > > > > Just realised that I can detect pagemap eviction by simply > enumerating > > the pagemaps when the session is detached. > > > > It seems to me that for wicket to support comet/bayeux, there will > > have to be a solution for the kind of problems I'm running > into here. > > I don't think pushing the problem to the application > developer (as I > > think you are suggesting) is acceptable in the long run. > > > > Cheers, Frank > > > > > >> From: Johan Compagner [mailto:[email protected]] > >> Sent: 24 January 2009 19:58 > >> > >> I think having references to or from pages is a bad idea > in wicket. > >> We serialize pages so if pages would have listeners then > the are also > >> serialized. If others reference pages then after > >> serialization/deserialization they point to the wrong instance. > >> > >> Way better is pure pull support. Components know where > thet get its > >> data from and they pull it on render and/or on a visitor > that checks > >> all components if they are changed. (and if changes add > them to ajax > >> request target) > >> > >> On 24/01/2009, [email protected] <[email protected]> > >> wrote: > >> > Use weakreferences to hold onto pages instead. > >> > > >> > -igor > >> > > >> > On 1/24/09, Frank van Lankvelt > <[email protected]> wrote: > >> >> I'm trying to get a page to observe a business object that > >> can send > >> >> events. The changes don't warrant a full page refresh, so > >> I want to > >> >> update only those parts of the page that have changed as a > >> result of > >> >> the events. > >> >> > >> >> I've seen wicketstuff-push, where a similar kind of > observation is > >> >> present in the Application. From what I could see, the > >> chat example > >> >> has the drawback that there is no *unregistering* of > >> listeners when > >> >> pages are disposed of, so there is a memory leak. (all > >> pages will be > >> >> kept in memory, being referenced directly by the service in the > >> >> application) > >> >> > >> >> There doesn't seem to be any support for cleaning up > >> pages, e.g. in > >> >> the form of listeners that an application could > register with the > >> >> session store. An alternative seems to be to implement my own > >> >> PageMap, but I'm reluctant to do that as there will be a lot of > >> >> copy/paste involved and the existing PageMap > >> implementations rely on > >> >> the fact that they're in the same package as Session. > A different > >> >> alternative is to store all the listeners in a registry > and use a > >> >> separate thread to remove any listeners that are > associated with > >> >> pages that are no longer stored. Is there a better way? > >> >> > >> >> Thanks, Frank > >> >> > >> >> > >> >> [email protected] www.onehippo.com > >> >> Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam > >> >> +31(0)20-5224466 > >> >> San Francisco Hippo USA Inc. 101 H Street, suite Q > Petaluma CA > >> >> 94952-5100 +1-877-41-HIPPO > >> >> > >> >> > >> >> > >> >> > >> > --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > [email protected] www.onehippo.com > > Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam > > +31(0)20-5224466 > > San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA > > 94952-5100 +1-877-41-HIPPO > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > [email protected] www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1-877-41-HIPPO --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
