Even with REPL_SYNC you need sticky sessions to work. It's possible to get two concurrent requests for the same session. 1) Think IFRAMEs or similar stuff. Nothing prevents browsers making simultaneous requests. 2) Similarly, the webapp can flush or even close the HttpResponse's OutputStream/PrintWriter, pushing content back to the browser before the session repl code considers the request done and replicates the session. Browser could parse that content and generate another request. There's a JIRA to look into preventing the webapp closing the OutputStream/PrintWriter, but preventing a flush could break some applications. I'll look at the mod_proxy bit in the morning. If the system's not under load and you have a reasonable delay between requests, the session should be replicating in time. One thing I just observed last week with 4.2.0 though was that there was occasional > 500 ms latency in replication message transmission when the UDP.enable_bundling attribute was set to "true" in tc5-cluster.sar/META-INF/jboss-service.xml. With that set to false the testsuite REPL_ASYNC tests worked fine with a 100 ms delay between requests. The same thing probably holds true in 4.0.5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044522#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...