Thanks for this information.
I do appreciate that the initial design priorities for wicket are for ease of development, and I think that that is a good thing.
I guess what I was looking for is not to have you provide a totally cluster-friendly implementation at 1.0, but rather to - if possible - put some extension points/structure in the api that would allow those who do require this functionality to create their own implementations - at their own risk as it were.
I've been working with Tapestry. It has been out for a few years now, and a large refactoring has just been done in 3.1 to allow for custom implemention of state managment (along with other areas.)
I think that if you plan to support high-volume clustering scenarios at some time in the future, it wouldn't hurt to look at where this logic could be plugged in, without necessarily providing any implementaions other than the default functionality at this stage.
With regard to the option of spending more on servers/network/bandwith. This is of course a possibility. But I have been working with clustered systems for a while, and you always try and minimize this type of traffic. Not only for the network IO and serialization issues (which can really hurt you in a high traffic environment) but also because it tends to be hard to test and a common point of failure. Also, when you have a cluster you are often using clustered caching systems (tangosol, jbostreecache etc), giving you fine-grained control over cluster state in your application.
see some more comments below...
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?
Yes. Even if there was a basic abstraction of how the main state object is retrieved that would help.
For example, the default implementation that comes with Wicket could use the HttpSession as it does now, but a developer could implement their own version that retrieves it in an application specific way.
In this scenario, I could remove pretty much all session serialization, and in the event of a session's primary server failing I could at least keep that user logged in on the secondary, but send them back to some start page and display a message or whatever.
In my experience I have only experienced server failure maybe once a year. It is less than desirable to be serializing after every single request to handle a once-a-year eventuality.
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
thx, 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
