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
