Thanks for your work Chris.
Eelco
Christopher Turner wrote:
More progress (but also more confusion!).....
I've been experimenting, and the problem just gets more and more
confusing! For example, when I'm starting the Tomcat instances from
my IDE I can't reproduce the problem where the request for the dynamic
image arrives before the page request has finished. However, I can
reliably reproduce it when running Tomcat from the command line! More
confusing is that however I start the tomcats, once the images are
cached in the browser everything works fine for a while and then the
hangman game suddenly stops synchronizing state across the cluster for
no apparent reason (no errors or anything - just stops keeping
everything in sync!). All of the session attributes indicate that they
are being changed and so on - I wonder if the multicast cluster
synchronization mechanism of Tomcat is perhaps not that reliable?
Experimenting with stuff outside of Wicket (just a servlet of my own
devising) to see if I can rationalise what is happening, I haven't
been able to reproduce the problems at all. I've tried different
buffer sizes, different flushing, different cache and expiry values,
different session objects and I just can't ever create a situation
where the resources on a page are requested before the page has
finished synchronizing across the cluster (even when I put thousands
of objects in the session!). I also can't ever create any cluster
synchronization problems.
This is just so weird!
All I can suggest at the moment is:
- If you are building a clustered application, then don't use any
components that hold image data relative to the session.
- Don't rely on the combination of Tomcat and Wicket if you are
developing mission-critical clustered applications.
Having spent a lot of time looking through the Tomcat implementation
of clustering, the one thing that I can say is that it is a fairly
basic solution to the problem. I suspect it has only really been
designed and tested for the clustering of fairly small size,
occasionally changing session data (e.g. id fields and minimal state
objects). It may just be that the data volumes, change frequency and
complexity involved in clustering Wicket page and component hierarchy
instances is just too much for the current Tomcat implementation
(especially given it's multicast approach and the impact on loosing
just one data packet).
I think my recommendation for Wicket 1.0 would therefore be to either
not use it for building clustered applications OR use sticky sessions
with clustering purely for fail-over support if one of the servers in
the cluster goes down. As we already have plans to make clustering
more powerful in v1.1 (through providing better ways to minimise
session data) this may be the best (and only) possible approach in
order to get the 1.0 release out.
Regards,
Chris
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
