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]

Reply via email to