Cluster Problem: Is there cache object size limits ?
I am testing the cluster function of TreeCache.
steps
1)One cache is started up first, it will be put about 10,000 objects.
2)The other cache is start up. it get data from the first cache
the testing source is
/////////////////////////////////////////////////////////////////////////////////
import org.jboss.cache.*;
import java.io.*;
public class MyTreeCache {
public static void main(String[] args) {
try{
TreeCache tree = new TreeCache();
PropertyConfigurator config = new PropertyConfigurator(); config.configure(tree, "META-INF/replAsync-service.xml");
tree.start(); // kick start tree cache
//the two line will be commented in second cache
//since the second cache just "read" data from the first
long time = fillCache(tree,"a",100000);
System.out.println("time = " +time);
while(true)
{
Thread.sleep(5000);
Node node = tree.get(new Fqn( new Object[] { "a" } ));
System.out.println("data size " +node.getDataKeys().size() );
}
}
catch(Exception e)
{
e.printStackTrace();
}
}
private static long fillCache(TreeCache cache, String regionRoot, int count)
throws Exception {
long time = System.currentTimeMillis();
for (int i = 0; i < count; i++) {
String item = "item"+i;
CacheMessage value = new CacheMessage(i);
cache.put(new Fqn( new Object[] { regionRoot} ), item, value);
}
return System.currentTimeMillis() - time;
}
}
class CacheMessage implements Serializable
{
public int index;
public byte [] body;
CacheMessage(int index)
{
body = new byte[100];
this.index = index;
}
}
///////////////////////////////////////////////////////////////////////////////////
when CacheMessage's member "body" szie is 100, the second cache will not able to get data from fisrt cache.
This is the error message
10:36:22,171 WARN [AckReceiverWindow] discarded msg with seqno=159 (next msg to
receive is 164)
10:36:22,171 WARN [AckReceiverWindow] discarded msg with seqno=145 .............................
but if the size is 50, it's ok
the cache config files replAsync-service.xml is copy from etc/META-INF directory. I adjust the log level to INFO.
is there any size limits in jboss TreeCache?
////////////////////////////////////////////////////////////////////////////////////
the tree config file
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
jboss:service=Naming
jboss:service=TransactionManager
<!--
Configure the TransactionManager
-->
org.jboss.cache.DummyTransactionManagerLookup
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ
<!--
Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
-->
REPL_ASYNC
<!--
Just used for async repl: use a replication queue
-->
false
<!--
Replication interval for replication queue (in ms)
-->
0
<!--
Max number of elements which trigger replication
-->
0
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
TreeCache-Cluster
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
-->
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.3" mcast_port="45566"
ip_ttl="64" ip_mcast="true"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="false"/>
<PING timeout="2000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<!-- <FD shun="true" up_thread="true" down_thread="true" />-->
<FD_SOCK/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192" up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false" up_thread="false"/>
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
<!--
Max number of entries in the cache. If this is exceeded, the
eviction policy will kick some entries out in order to make
more room
-->
2000000
<!--
Whether or not to fetch state on joining a cluster
-->
true
<!--
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
5000
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
10000
<!-- Max number of milliseconds to wait for a lock acquisition -->
15000
<!-- Max number of milliseconds we hold a lock (not currently
implemented) -->
60000
<!-- Name of the eviction policy class. Not supported now. -->
<!-- Uncomment to get a graphical view of the TreeCache MBean above -->
<!-- -->
<!-- jboss.cache:service=TreeCache-->
<!-- jboss.cache:service=TreeCache-->
<!-- -->
