-
1. Re: is it possible to have in-memory caching if running on m
ben.wang May 23, 2005 5:46 PM (in response to enyedi)Yes, use the REPL_SYNC or REPL_ASYNC mode, for example.
Check the documentation.
-Ben -
2. Re: is it possible to have in-memory caching if running on m
enyedi May 24, 2005 3:57 AM (in response to enyedi)Hello,
This is exactly what I have been using - REPLY_ASYNC. I have also tried using RmiDelegatingCacheLoader instead of FileCacheLoader (with the host set explicitly to one of the IPs in the cluster, the same IP in the XMLs on each machine). Nothing worked. The two test instances both use the same node to store keys, of course.
Here is the complete configuration file:<server> <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache"> <depends>jboss:service=Naming</depends> <depends>jboss:service=TransactionManager</depends> <!-- Configure the TransactionManager --> <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute> <!-- Node locking level : SERIALIZABLE SERIALIZABLE (default) READ_COMMITTED READ_UNCOMMITTED NONE --> <attribute name="IsolationLevel">SERIALIZABLE</attribute> <!-- Valid modes are LOCAL REPL_ASYNC REPL_SYNC --> <attribute name="CacheMode">REPL_ASYNC</attribute> <!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> <attribute name="ClusterName">test</attribute> <!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml <attribute name="ClusterProperties"></attribute> --> <attribute name="ClusterConfig"> <config> <!-- 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="48866" 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"/> </config> </attribute> <!-- 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 --> <attribute name="InitialStateRetrievalTimeout">5000</attribute> <!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">10000</attribute> <!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">15000</attribute> <!-- Name of the eviction policy class. --> <attribute name="EvictionPolicyClass"></attribute> <attribute name="FetchStateOnStartup">true</attribute> <attribute name="CacheLoaderClass">org.jboss.cache.loader.RmiDelegationCacheLoader</attribute> <attribute name="CacheLoaderConfig"> host=192.168.97.148 </attribute> <attribute name="CacheLoaderShared">true</attribute> <attribute name="CacheLoaderPreload">/</attribute> <attribute name="CacheLoaderFetchTransientState">true</attribute> <attribute name="CacheLoaderFetchPersistentState">true</attribute> </mbean> </server>
Thank you for your help. -
3. Re: is it possible to have in-memory caching if running on m
dnielben May 27, 2005 3:31 PM (in response to enyedi)I asume that you are trying to have a cahe synchronized in two machines(This is the default behavior if you have sychronization activated). so in Fact I think that the performance problem is the precense of the CacheLoader.
Do you need the cache data to be persisted? if not why do you need a cacheloader?
If you avoid the use of the cache loader, or you try to use a REPL_SYNC(maybe the synchornization had not happen when you try to tead) the performance will improve.
Do this help you or did I misundertand your request? -
4. Re: is it possible to have in-memory caching if running on m
enyedi May 27, 2005 4:24 PM (in response to enyedi)Yes, this is exactly what I want to obtain - both [real-time] synchronization and [better] performance. I'm actually trying to use JBossCache as a data sharing utility.
You suggest that using REPL_SYNC this synchronization won't happen instantly. The "handshake" test was fairly permissive spped-wise, in the sense that a human operator placed the value in cache and literally yelled at the other user to try and get the value.
I do not need data to be persisted, but the above test failed if I did not use a cache loader - a FileCacheLoader, to be exact. But performance obviously decreases a lot - I have a second test to measure that.
Suggestion for making it easier for users to configure JBossCache: offer a small console-based utility, to help perform this "handshake" test and avoid later debugging efforts. Once a configuration works, the xml file can be used in the real application. I am planning to contribute myself - will have to study
submission policies first, though.
Thank you for the suggestions. I will keep digging starting from those. -
5. Re: is it possible to have in-memory caching if running on m
dnielben May 27, 2005 5:33 PM (in response to enyedi)I think you are not starting the caches in the same group, in fact from your response I asume that boot chaes are using the same cache loder (sharing disk?) and the delay is because the sharing mechanism that you are using is , Ithink, the persistence layer.
I suggest review the documentation and be sure to start both caches in the same group Cluster in this case. Still you must use the repl_sync.
Are you using thesame conf file in both computers? -
6. Re: is it possible to have in-memory caching if running on m
enyedi May 27, 2005 5:38 PM (in response to enyedi)Yes, the same config file is on both computers. When using FileCacheLoader, the location attribute was set with respect to each disk.
-
7. Re: is it possible to have in-memory caching if running on m
dnielben May 27, 2005 6:24 PM (in response to enyedi)I suggest to try this file, It came with the distribution and is commented. Use repl_sync and no cache loader. Try with it.
<?xml version="1.0" encoding="UTF-8"?> <!-- ===================================================================== --> <!-- --> <!-- Sample TreeCache Service Configuration --> <!-- --> <!-- ===================================================================== --> <server> <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/> <!-- ==================================================================== --> <!-- Defines TreeCache configuration --> <!-- ==================================================================== --> <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache"> <depends>jboss:service=Naming</depends> <depends>jboss:service=TransactionManager</depends> <!-- Configure the TransactionManager --> <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute> <!-- Isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE --> <attribute name="IsolationLevel">REPEATABLE_READ</attribute> <!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC --> <attribute name="CacheMode">REPL_SYNC</attribute> <!-- Just used for async repl: use a replication queue --> <attribute name="UseReplQueue">false</attribute> <!-- Replication interval for replication queue (in ms) --> <attribute name="ReplQueueInterval">0</attribute> <!-- Max number of elements which trigger replication --> <attribute name="ReplQueueMaxElements">0</attribute> <!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> <attribute name="ClusterName">TreeCache-Cluster</attribute> <!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml <attribute name="ClusterProperties"></attribute> --> <attribute name="ClusterConfig"> <config> <!-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2" --> <!-- 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="48866" 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"/> </config> </attribute> <!-- Whether or not to fetch state on joining a cluster --> <attribute name="FetchStateOnStartup">true</attribute> <!-- 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 --> <attribute name="InitialStateRetrievalTimeout">5000</attribute> <!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">10000</attribute> <!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">15000</attribute> <!-- Name of the eviction policy class. Not supported now. --> <attribute name="EvictionPolicyClass"></attribute> <!-- <attribute name="CacheLoaderClass">org.jboss.cache.loader.bdbje.BdbjeCacheLoader</attribute> <attribute name="CacheLoaderConfig"> location=c:\\tmp\\bdbje </attribute> <attribute name="CacheLoaderShared">true</attribute> <attribute name="CacheLoaderPreload">/</attribute> --> <!-- <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute> <attribute name="CacheLoaderConfig"> location=c:\\tmp </attribute> <attribute name="CacheLoaderShared">true</attribute> <attribute name="CacheLoaderPreload">/</attribute> --> </mbean> <!-- Uncomment to get a graphical view of the TreeCache MBean above --> <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">--> <!-- <depends>jboss.cache:service=TreeCache</depends>--> <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>--> <!-- </mbean>--> </server>