>members of the cluster rise so high that the machine became unusable. what OS are you on, I would be very interested to see what threads went high up. For Solaris there is a free tool called ThreadAnalyser which tells you exactly what the threads are doing. I am running load tests with hundreds of clients and I don't experience this CPU rise.
>One thing I saw in the logs, which i'm unsure is the cause or a symptom, is that all >member >periodically saw other members of the cluster leaving then rejoining again 1 second later This is of course bad, increasing the "mcastDropTime" should prevent this. >My intended course of action was to retain the clustering >and write the sessions to a shared disk to Using the persistence manager and a shared file system, will achieve this. I of course, am more interested in figuring out what problems you are having and why :) since I haven't been able to reproduce those myself. Let me know if you would want to volunteer some of your time to work with me on this. I would also be interested in what your average cluster send times are and what the average message size is, should also have been printed to your logs. Filip ----- Original Message ----- From: "Dale, Matt" <[EMAIL PROTECTED]> To: "Tomcat Users List (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, June 08, 2004 10:44 AM Subject: RE: persist sessions in a clustered environment Its not that the memory replication didnt work, it worked very well just seemed to have exteme problems with it under load, there may have been other factors though. Using clustering and in-memory replication we on fairly regular occasion saw the load of one or more members of the cluster rise so high that the machine became unusable. Turning off the clustering completly but keeping the load balancing seems to have sorted this. One thing I saw in the logs, which i'm unsure is the cause or a symptom, is that all member periodically saw other members of the cluster leaving then rejoining again 1 second later. I'm not sure what would cause this but I suppose too much network traffic from the in-memory session replication could cause a hold up, although I find it hard to believe that it would be over 3 seconds. Or as a cause of the problems, every time a member rejoins, all of the active sessions will have to be shared between the members so increased network traffic there. If you have any ideas on that i'd be grateful. My intended course of action was to retain the clustering and write the sessions to a shared disk to avoid the network traffic associated. My 1 question would be here, is that say I have 2 tomcats TomcatA and TomcatB, and they write their sessions to a shared file system using PersistenceManager, will each of them know about the sessions belonging to the other tomcat? Ta Matt > persist sessions in a clustered environmentuse the PersistenceManager instead of the > clustering if all you want is to write sessions to a file system. > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html > Did you need any help figuring out why in memory replication didn't work? > Filip ----- Original Message ----- From: Dale, Matt To: Tomcat Users List (E-mail) Sent: Monday, June 07, 2004 4:03 PM Subject: persist sessions in a clustered environment Hi, We have been experiencing problems with our cluster using in-memory replication so we are looking into other ways in which to replicate the sessions. Our first step will be to switch to asynchronous mode for the replication from pooled but what i'm stuck with is replicating sessions to a shared file system. Basically I want to know how to do it or if someone can point me towards examples. Ta Matt ------------------------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -------------------------------------------------------------------------------- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
