I've had a problem with send/receive buffers filling up because FastAsyncSocketSender doesn't read the Ack from the other cluster node. Does netstat -n give you full buffers on the cluster tcp connections (port 8015 I think)? This might cause Tomcat to stack up a lot of session data in its internal queue's. Does kill -QUIT give you traces with Cluster-FastAsyncSender threads blocking on Socket.write or something similar?
Ronald. On Sun Mar 30 11:14:02 CEST 2008 Tomcat Users List <users@tomcat.apache.org> wrote:
On Sun, Mar 30, 2008 at 1:49 AM, David Rees <[EMAIL PROTECTED]> wrote: > I have a 2-Tomcat 5.5.26 cluster running 64bit Java which leaks > ClusterData and LinkObject objects. > > I have a hprof dump which shows over 600k of each of those classes. > Analyzing them with a profiler reveals an endless loop of > LinkObject.next references through all 600k of them. There were about > 6000 sessions actually active at the time according to the Tomcat > manager. > > So the question is - why are all these LinkObjects piling up and > references being held on to? A bit more data - With a smaller dump (a few hours after a Tomcat restart instead of a day) I was able to trace down the source of one of the ClusterData classes - FastAsyncSocketSender. From my understanding of the clustering software, it appears that Tomcat is trying to send messages to the other Tomcat but it isn't receiving them? Shouldn't it drop membership and give up? I suspect that some reconfiguration of the cluster could avoid this... -Dave --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
