On Mon, Mar 31, 2008 at 5:06 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > David Rees wrote: > > I've got a cluster in my test lab with the following configuration on > 5.5.26: > > > > <Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"/> > > > > Looking at /manager/jmxproxy?qry=*:* I see the same thing on both > > nodes (extra info snipped for brevity): > > > > Name: Standalone:type=ClusterSender,host=www.example.local > > modelerType: org.apache.catalina.cluster.tcp.ReplicationTransmitter > > info: ReplicationTransmitter/3.0 > > replicationMode: fastasyncqueue > > ackTimeout: 15000 > > autoConnect: false > > waitForAck: true > > > > Name: > Standalone:type=IDataSender,host=www.example.local,senderAddress=10.2.1.170,senderPort=8015 > > modelerType: org.apache.catalina.cluster.tcp.FastAsyncSocketSender > > info: FastAsyncSocketSender/3.1 > > waitForAck: false > > > > Name: Standalone:type=ClusterReceiver,host=www.example.local > > modelerType: org.apache.catalina.cluster.tcp.SocketReplicationListener > > info: SocketReplicationListener/1.3 > > sendAck: true > > > > those settings are no good. waitForAck and sendAck must have the same > value everywhere > even if it seems to work fine, you're asking for trouble, at some point, > you'll fill up socket buffers etc
This is with the default cluster configuration. So should I open a bug for this, or are you already working on it? IMO, the Cluster should default to sane defaults. How does the cluster avoid filling up queues when acks are not being sent? Does it rely on cluster membership? So in theory if a cluster member is hung, it will drop it's queue after the mcastTimeOut is reached? -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]