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
