4 Replies Latest reply on Apr 14, 2008 3:05 PM by brian.stansberry

    Cache Loader Persistence

    kringdahl

      I'm seeing various topics in the forum that talk about this issue, but I'm not getting a clear picture on what the root cause might be. Anyway, we're seeing an issue where the in-memory state of a node is getting updated, but this does not appear to take effect in the JDBC data source we're using. So, the application runs, modifications are made to the nodes, and data is accurate. Upon restart and preloading of the cache from the cache loader, the changes previously made are not reflected. Here is my cache config file. Any thoughts on what might cause this problem?



      <?xml version="1.0" encoding="UTF-8"?>
      
      <!-- ===================================================================== -->
      <!-- -->
      <!-- Sample TreeCache Service Configuration -->
      <!-- -->
      <!-- ===================================================================== -->
      
      <server>
      
       <!-- ==================================================================== -->
       <!-- Defines TreeCache configuration -->
       <!-- ==================================================================== -->
      
       <mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
       name="jboss.cache:service=TreeCache">
      
       <depends>jboss:service=Naming</depends>
       <depends>jboss:service=TransactionManager</depends>
      
       <!--
       Configure the TransactionManager
       -->
       <attribute name="TransactionManagerLookupClass">org.jboss.cache.transaction.GenericTransactionManagerLookup
       </attribute>
      
       <!--
       Isolation level : SERIALIZABLE
       REPEATABLE_READ (default)
       READ_COMMITTED
       READ_UNCOMMITTED
       NONE
       -->
       <attribute name="IsolationLevel">READ_UNCOMMITTED</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 TreeCache nodes in a
       cluster in order to find each other. Needs to be different in order to maintain
       separate caches
       -->
       <attribute name="ClusterName">dtFabricCache</attribute>
      
       <!--Uncomment next three statements to enable JGroups multiplexer.
      This configuration is dependent on the JGroups multiplexer being
      registered in an MBean server such as JBossAS. -->
       <!--
       <depends>jgroups.mux:name=Multiplexer</depends>
       <attribute name="MultiplexerService">jgroups.mux:name=Multiplexer</attribute>
       <attribute name="MultiplexerStack">fc-fast-minimalthreads</attribute>
       -->
      
       <!-- JGroups protocol stack properties.
       ClusterConfig isn't used if the multiplexer is enabled and successfully initialized.
       -->
       <attribute name="ClusterConfig">
       <config>
       <UDP mcast_addr="228.10.10.10"
       mcast_port="45588"
       tos="8"
       ucast_recv_buf_size="20000000"
       ucast_send_buf_size="640000"
       mcast_recv_buf_size="25000000"
       mcast_send_buf_size="640000"
       loopback="false"
       discard_incompatible_packets="true"
       max_bundle_size="64000"
       max_bundle_timeout="30"
       use_incoming_packet_handler="true"
       ip_ttl="2"
       enable_bundling="false"
       enable_diagnostics="true"
      
       use_concurrent_stack="true"
      
       thread_naming_pattern="pl"
      
       thread_pool.enabled="true"
       thread_pool.min_threads="1"
       thread_pool.max_threads="25"
       thread_pool.keep_alive_time="30000"
       thread_pool.queue_enabled="true"
       thread_pool.queue_max_size="10"
       thread_pool.rejection_policy="Run"
      
       oob_thread_pool.enabled="true"
       oob_thread_pool.min_threads="1"
       oob_thread_pool.max_threads="4"
       oob_thread_pool.keep_alive_time="10000"
       oob_thread_pool.queue_enabled="true"
       oob_thread_pool.queue_max_size="10"
       oob_thread_pool.rejection_policy="Run"/>
      
       <PING timeout="2000" num_initial_members="3"/>
       <MERGE2 max_interval="30000" min_interval="10000"/>
       <FD_SOCK/>
       <FD timeout="10000" max_tries="5" shun="true"/>
       <VERIFY_SUSPECT timeout="1500"/>
       <pbcast.NAKACK max_xmit_size="60000"
       use_mcast_xmit="false" gc_lag="0"
       retransmit_timeout="300,600,1200,2400,4800"
       discard_delivered_msgs="true"/>
       <UNICAST timeout="300,600,1200,2400,3600"/>
       <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
       max_bytes="400000"/>
       <pbcast.GMS print_local_addr="true" join_timeout="5000"
       join_retry_timeout="2000" shun="false"
       view_bundling="true" view_ack_collection_timeout="5000"/>
       <FRAG2 frag_size="60000"/>
       <pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>
       <!-- <pbcast.STATE_TRANSFER/> -->
       <pbcast.FLUSH timeout="0"/>
       </config>
       </attribute>
      
      
       <!--
       Whether or not to fetch state on joining a cluster
       NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive.
       -->
       <attribute name="FetchInMemoryState">true</attribute>
      
       <!--
       The max amount of time (in milliseconds) we wait until the
       state (ie. the contents of the cache) are retrieved from
       existing members in a clustered environment
       -->
       <attribute name="StateRetrievalTimeout">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">false</attribute>
      
       <!-- Cache Loader configuration block -->
       <attribute name="CacheLoaderConfig">
       <config>
       <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
       <passivation>false</passivation>
       <preload>/</preload>
       <shared>false</shared>
      
       <!-- we can now have multiple cache loaders, which get chained -->
       <cacheloader>
       <class>org.jboss.cache.loader.JDBCCacheLoader</class>
      
       <properties>
       cache.jdbc.table.name=dht
       cache.jdbc.table.primarykey=dht_pk
       cache.jdbc.table.create=true
       cache.jdbc.table.drop=false
       cache.jdbc.fqn.column=fqn
       cache.jdbc.fqn.type=varchar(255)
       cache.jdbc.node.column=value
       cache.jdbc.node.type=LONGBLOB
       cache.jdbc.parent.column=parent_fqn
       cache.jdbc.datasource=java:/jdbc/FabricDS
       cache.jdbc.sql-concat=concat(1,2)
       </properties>
      
       <!-- whether the cache loader writes are asynchronous -->
       <async>false</async>
      
       <!-- only one cache loader in the chain may set fetchPersistentState to true.
       An exception is thrown if more than one cache loader sets this to true. -->
       <fetchPersistentState>true</fetchPersistentState>
      
       <!-- determines whether this cache loader ignores writes - defaults to false. -->
       <ignoreModifications>false</ignoreModifications>
      
       <purgeOnStartup>false</purgeOnStartup>
       </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>
      


        • 1. Re: Cache Loader Persistence
          kringdahl

          For what it's worth this is running JBC 2.0.0.GA on AS 4.2.2.GA

          • 2. Re: Cache Loader Persistence
            kringdahl

            I've actually reproduced this behavior with a slight variant of the pojo cache example that comes with 2.0.0. So, this is not related to JBoss AS at all. I'm happy to share the code if someone can help.

            • 3. Re: Cache Loader Persistence
              kringdahl

              For the benefit of anyone else that comes across this issue... It appears that aspectizing your POJOs (using @Replicable) is required in order for them to be updated in a secondary persistent store (e.g. file or jdbc). This is not clear from the JBC documentation. But as soon as we instrumented our objects, the secondary data store was kept in sync.

              • 4. Re: Cache Loader Persistence
                brian.stansberry

                The cache configuration file you posted above is not for PojoCache. For PojoCache the value of the code attribute of the mbean would need to be "org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper".

                You mentioned the pojo cache examples. so I assume you want to use PojoCache. And if you want to use PojoCache you should annotate your classes @Replicable.

                All that said, it's odd that if you had the problem you described if you used just a plain JBoss Cache with non-@Replicable objects.