Good news it that the current release candidate seems to have got the basics of clustering right. Session attributes are only updated when they have actually changed and only the pages involved in handling a particular request get marked as dirty. Also, session changes are only applied on the handler request and not the redirect request so that the cluster is only synchronized once for each page render. Also, most applications that I have tested SEEM to work fine in a clustered environment (although see the further details below). However, I am still having problems with Hangman. It SEEMS to work absolutely fine in a cluster if the browser has all of the button images in its cache. If, however, you clear the cache and start a new game then all of the Tomcat cluster synchronization issues start appearing again as soon as the browser starts trying to load the images.
Having spent hours trying to debug this problem I'm almost 95% convinced that I have found a bug in the tomcat clustering code. The reason that I say this is that I can reproduce the exact same problem in a 30 line servlet of my own - no Wicket code involved. Having built a tomcat version with my own debug I am fairly certain that the cluster implmentation is faulty when used with the redirect pattern or when using the a servlet in the web application to serve up resources such as images, javascript or css. What seems to be happening is as follows:
1) Request arrives at serverA. It sends this to the application servlet. This servlet generates the HTML response and changes a session attribute. It then returns the response
2) serverA sends its changed session attribute to serverB and clears its delta change object cache
3) serverB receives the changed attribute and updates its copy of the session. However, it DOESN'T clear its cache, and thus holds onto the delta change object
4) Request for resource (e.g. image) arrives at serverB. It sends this to the application servlet. The servlet writes the resource to the response. It doesn't change any session attributes
5) serverB notes that its delta change cache is not empty (still contains the previous object) and so it sends this object back to serverA
6) serverA receives the changed attribute and updates its copy of the session. However, it DOESN'T clear its cache, and thus holds onto the delta change object
7) This goes on forever with the two servers continually exchanging the same delta change object back and forth
Obviously, this is very inefficient and rather stupid. However, for resources such as javascript files and css files I can get the thing to fall into a heap. It only occurs for images - but this may just be because the images are much larger than the css and javascript content I have been testing with. I'm going to spent a bit more time proving this is exactly the problem then I'll raise a bug with the tomcat team.
However, I have tried a fix to the tomcat code that clears the delta change cache after the session has been synchronized and this solves all of the problems with my test application. Unfortunatly, when I then try to run Hangman on my modified tomcat servers it falls over with a different problem. Basically, it all runs fine until the Guess page gets rendered. The redirect happens and all is well. ServerA loads the Guess.html markup file (which involves generating all of the button images) and sends the HTML content back to the client. From that point on, all image requests that are sent to serverA are satisfied correctly, while all image requests that go to serverB result in an exception:
wicket.WicketRuntimeException: Could not find resource referenced by key wicket.examples.hangman.Letter/a_enabled
at wicket.protocol.http.WebRequestCycle.resourceReference(WebRequestCycle.java:454)
at wicket.protocol.http.WebRequestCycle.parseRequest(WebRequestCycle.java:206)
at wicket.RequestCycle.request(RequestCycle.java:367)
...
This does actually sound plausible in that all of the images are being created on the server that handles the rendering of the guess page and are bound into the application object for that server. Then, only the shared resource reference object is synchronized to the other server, not the physical image object that was bound into the application - and which doesn't exist on serverB. However, my brain hurts from trying to debug tomcat that I may have completely misunderstood what is going on in Wicket! I'll look again tomorrow maybe.
regards, Chris
------------------------------------------------------- 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
