RE: Observation and page (map) eviction
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:jcompag...@gmail.com] Sent: 25 January 2009 21:55 To: users@wicket.apache.org 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 f.vanlankv...@onehippo.com 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:jcompag...@gmail.com] 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, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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
RE: Observation and page (map) eviction
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:jcompag...@gmail.com] 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, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional
Re: Observation and page (map) eviction
What we doe is pretty simple Just remeber the last rendered value of a component. Then you can compare this to something and you know if it is changed ore not. On 25/01/2009, Frank van Lankvelt f.vanlankv...@onehippo.com 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:jcompag...@gmail.com] 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, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc.
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 f.vanlankv...@onehippo.com 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:jcompag...@gmail.com] 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, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org f.vanlankv...@onehippo.com www.onehippo.com Amsterdam Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco Hippo USA Inc. 101 H Street,
Observation and page (map) eviction
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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Observation and page (map) eviction
Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Observation and page (map) eviction
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, igor.vaynb...@gmail.com igor.vaynb...@gmail.com wrote: Use weakreferences to hold onto pages instead. -igor On 1/24/09, Frank van Lankvelt f.vanlankv...@onehippo.com 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 f.vanlankv...@onehippo.com 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
