We struggled with a similar bug during load testing of our last release. It turned out to be a non-static anonymous inner class of a page class being put into session. This inner class was calling the getter for an injected state object on the outer page class. Non-static inner classes hold an implicit reference to the instance of the outer class in which it was created. If the timing was exactly right, a user would end up getting the still-cached state object from a page that was still in the page pool (the generated code for a state injection caches the object like any other property, and like any other property the cache isn't reset until the page is attached). I'm not sure that all made sense, but look out for non-static inner classes of pages. If you pass them outside of a particular page instance, you have to remember that any calls to the outer class methods are going through a reference to the creating outer class instance. If that outer instance is in the page pool, it hasn't been cleaned up from the last request and may return old data. Other than that, we've had no instances of crossovers like you're talking about. jeff
________________________________ From: Henri Dupre [mailto:[EMAIL PROTECTED] Sent: Sat 12/30/2006 12:24 AM To: Tapestry users Subject: visit objects swapped between requests on high load On this high christmas server load, the most rare problems seem to face at a higher rate... The worst one is that with our tapestry app (4.0), on rare occasions on concurrent requests (really concurrent, on the apache logs they show with <1s difference) from different users, the ASOs get swapped between requests from different users!!! In Tapestry 4.0 most internal services seem to be have singleton instances in the engine with very few threaded services. Could this affect concurrent requests being executed *at the same time*? Any chance this could come from Tomcat/JK? Anyone heard of such issue (tomcat 5.5.17)? -- Henri Dupre Actualis Center
