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
