i think i explained as much as i've guessed so far. the basic idea is that
1. removeAll() is really only useful for components whose model is out of sync, as identified by modelChangedStructure() (not modelChanged()!). we could really hide (make private) removeAll() and throw excetpions if add() is called after a page is rendered, making update() the only post-rendering page mutator. this way we /just/ solve your problem and we don't "solve" any others. i hate removeAll() too.
2. we can do a better job of examining components whose modelChangedStructure() by traversing the children of the component and looking at the parent hierarchy. if the model is not on a form, i don't think we need to do anything at all. as you point out, staleness detection of links is something you can handle manually. the object the link points to either will or won't be there. the real value is if the model which changed structure is on a form. and there we only need to consider marking the page stale if the model that changed structure is attached to one or more components that are model mutators. i think that's pretty much any FormComponent, actually.
what i think modelChangedStructure() does is relieve the need to think about staleness so much. as you point out, you could mark pages stale by hand. but if you just automatically call modelChangedStructure() all the time, you can stop worrying about when you need to do that. you will still need to handle missing objects and such, but as you point out, you're going to need to do that anyway.
make sense now?
jon
Johan Compagner wrote:
i am very curious how you are going to fix removeAll problems (that is in my eyes exactly the same as replace) by just better staleness support....
Jonathan Locke wrote:
+1
that and staleness/cloning. ;-)
i can't spend much more time debating this via email. it's too time consuming.
i'm very strongly -1 on adding cloning to 1.0.
my mind is certainly open for 1.1 if we can answer a ton of questions that we're mainly dodging/avoiding right now. however, i suspect that improvements to the current staleness detection would solve everything except the issue that eelco and johan are working on... cases where components want to call replace() to change the page dynamically. there might be a way to restrict cloning to just that problem and i might be in favor of that... in general, i think we need to do a heck of a lot more thinking here and that being in the same room with a whiteboard would really help matters! ;-)
best,
jon
Eelco Hillenius wrote:
I would be +1 for making clustering *the* issue of our gathering on march the 19th. Chris, would it be a good idea if you would lead the topic then?
Eelco
Christopher Turner wrote:
Hi Evan,
What you are asking regarding clustering is not possible in the current Wicket version (e.g. for the upcoming 1.0 release). We are planning to take a long hard look at clustering improvements as part of 1.1.
Your main issue seems to be that Wicket makes the session dirty on every single request and that this then requires the session to be replicated across the cluster. Am I correct?
The way Wicket currently works is that it makes your development much simpler by taking care of state tracking, stale pages, back buttons and so on. However, this does mean that EVERY request needs to alter some state related data (even if it is just incrementing a render count flag). Thus, we always need to make the session dirty in order to replicate these changes across the cluster. While I appreciate that this not an ideal situation, the 1.0 release of Wicket is more about making web application development much easier and less costly - perhaps allowing you to spend more on processor/memory/network bandwidth on the deployment platform.
For 1.1, there are a number of clustering related points under consideration, including:
- Minimising the data in the session by providing options to just cluster models and basic state information as opposed to the entire page/component hierarchy
- Minimising the number of time that we make the session dirty
- Looking at integration with and alternative caching solution to avoid session changes
If you have any other thoughts or suggestions then we would welcome them in preparation for this improvement work in 1.1
Regards, Chris
> Hello again,
>
> As I said in an earlier post I am just beginning to research wicket for
> a project. I have a need for clustering and failover so want to get your
> opinions on something.
> A possibiliy for my project could be to use Wicket and implement
> missing pieces myself. As such I want to get a feel for what may be
> involved. So here goes:
>
> For my project the application will be deployed on a cluster of app
> servers with in-memory replication using a sticky primary, with
> secondary backup server for a session. In this model server failure is a
> rare occurence, but when it does happen the idea would be for my
> application to retrieve whatever state is necessary on the new server.
> The problem for this with the current Wicket code is that
> HttpSession.setAttribute is called for every request to the server,
> trigering serialization of the session every time. This is problematic
> in terms of performance.
> The ideal situation would be for an extension point that allows my
> application code to determine what stateful information needs to be
> shared on the cluster and when.
> It seems like this would be not too hard to implement, by letting my
> application code determine how the component model objects are loaded
> and persisted.
> Then the only code change to the framework needed would be a means of
> managing the setAttribute calls, and ensuring that only the minimum
> state is replicated (probably some uid at the point of session creation.)
> So, to make a long story short, my question is will it be easy to
> delegate the loading of model data to app layer code (seems like it
> should be from what I can tell), and are there any implications for the
> framework in rebuilding component heirarchies on a fresh server, i.e. do
> they rely on non-application-specific state?
>
> Any suggestions of where to begin looking with this would be helpful.
>
> FYI, I have been looking at the same issue with Tapestry. In Tapestry
> 3.1 this is supported by implementing a custom ApplicationStateManager,
> giving fine grained control over what is stored in the session.
>
> Thanks,
>
> Evan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
