[jboss-user] [JBossCache] - Funky behaviour with JBC1.4 and replication
jorgemoralespou_2
do-not-reply at jboss.com
Mon Dec 10 05:37:53 EST 2007
Hi, we have a cache configured like this:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- SOM Services Provisioning Cache 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=SOMServicesProvisioningCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
| <depends>
| jboss.jca:name=jdbc/somservices,service=DataSourceBinding
| </depends>
|
| <attribute name="TransactionManagerLookupClass">
| org.jboss.cache.JBossTransactionManagerLookup
| </attribute>
|
| <!--
| Isolation level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">NONE</attribute>
|
| <!--
| Valid modes are LOCAL
| REPL_ASYNC
| REPL_SYNC
| INVALIDATION_ASYNC
| INVALIDATION_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">
| SOMServicesProvisioning-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="${jboss.cache.SOMServicesProvisioningCache.addr:228.1.2.3}"
| mcast_port="${jboss.cache.SOMServicesProvisioningCache.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="FetchInMemoryState">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">15000</attribute>
|
| <!-- Number of milliseconds to wait until all responses for a
| synchronous call have been received. -->
| <attribute name="SyncReplTimeout">15000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">10000</attribute>
|
| <!-- Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped
| class loader, e.g., inside an application server. Default is "false". -->
| <attribute name="UseRegionBasedMarshalling">true</attribute>
|
| <attribute name="CacheLoaderConfiguration">
| <config>
| <passivation>false</passivation>
| <preload>/</preload>
| <shared>true</shared>
| <cacheloader>
| <class>
| org.jboss.cache.loader.ClusteredCacheLoader
| </class>
| <properties>timeout=1000</properties>
| <async>true</async>
| <fetchPersistentState>false</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
|
| </cacheloader>
| <!--
| som.cache.driver=${db.som.driver}
| som.cache.url=${db.som.url}
| som.cache.user=${db.som.user}
| som.cache.password=${db.som.password}
| -->
| <cacheloader>
| <class>
| org.jboss.cache.loader.JDBCCacheLoader
| </class>
| <properties>
| cache.jdbc.datasource=java:jdbc/somservices
| cache.jdbc.table.name=services_provisioning
| cache.jdbc.table.create=true
| cache.jdbc.table.drop=false
| cache.jdbc.table.primarykey=jbosscache_pk
| cache.jdbc.fqn.column=fqn
| cache.jdbc.fqn.type=varchar(255)
| cache.jdbc.node.column=node
| cache.jdbc.node.type=blob
| cache.jdbc.parent.column=parent
| </properties>
| <async>false</async>
| <fetchPersistentState>true</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
| </cacheloader>
| </config>
| </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>
|
We are experiencing this behaviour (in a two node cluster (ClusterA-ClusterB):
We put a value on ClusterA.
| Value is stored on cache and DB
| Modify an attribute of the node in clusterA
| Value is changed in clusterB
| It seems value is not changed in DB
| After some time, initial value (the value in DB) is retrieved in clusterB
|
| How can this be possible??? How can I avoid this?
| Reading http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124722&start=10&postdays=postDays&postorder=postOrder&highlight=highlight it seems like ClusteredCacheLoader is not for what it seems to be. Do I need a ChainingCacheLoader??? Do I need a ClusteredCacheLoader if I dont have Evictions??? Would it load a value first from the other node of the cluster, and if not found from DB? Why is not storing correct value in DB?
|
| I`m getting really mad, because this is already in production and we`re wasting to much time with unexpected behaviour that I can`t expect from reading documentation. Although I'm also reading JBC2x docs.
|
| Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111562#4111562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4111562
More information about the jboss-user
mailing list