7 Replies Latest reply on Feb 1, 2009 5:31 PM by bobbiee

    very strange behaviour of jboss cache 1.4.1

    bobbiee

      Hello.

      I am experiencing really strange problem here. When I start jboss, some entites are pre-loaded into cache. Then, if I load more and more entities in there, suddenly cache become empty and start all over - this causes dbs traffic of course.

      On my local pc, if there are some nodes in the cache (sometimes 275, sometimes 900 it depends which operation I run), then cache gets suddenly clean, and when operation finish, the number of nodes in cache is 10 - and its only directories.

      On production server this process repeats and repeats.

      Could somebody help me to keep the nodes inside the cache bit longer??

      Here is my configuration

      <?xml version="1.0" encoding="UTF-8"?>
      <server>
      
       <!-- ==================================================================== -->
       <!-- Defines TreeCache configuration -->
       <!-- ==================================================================== -->
       <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=EJB3EntityTreeCache">
       <depends>jboss:service=Naming</depends>
       <depends>jboss:service=TransactionManager</depends>
      
       <!-- Configure the TransactionManager -->
       <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
      
       <!--
       Node locking level : SERIALIZABLE
       REPEATABLE_READ (default)
       READ_COMMITTED
       READ_UNCOMMITTED
       NONE
       -->
       <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
      
       <!-- Valid modes are LOCAL
       REPL_ASYNC
       REPL_SYNC
       -->
       <attribute name="CacheMode">REPL_SYNC</attribute>
      
       <!-- Name of cluster. Needs to be the same for all clusters, in order
       to find each other -->
       <attribute name="ClusterName">EJB3-entity-cache</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="${jboss.partition.udpGroup:228.1.2.3}" mcast_port="43333" ip_ttl="2" 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" />
       <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
       <pbcast.NAKACK gc_lag="50" max_xmit_size="8192" retransmit_timeout="600,1200,2400,4800" 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="false" down_thread="false" />
       </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">org.jboss.cache.eviction.LRUPolicy</attribute>
      
       <!-- Specific eviction policy configurations. This is LRU -->
       <attribute name="EvictionPolicyConfig">
       <config>
       <attribute name="wakeUpIntervalSeconds">5</attribute>
       <!-- Cache wide default -->
       <region name="/_default_">
       <attribute name="maxNodes">5000</attribute>
       <attribute name="timeToLiveSeconds">1000</attribute>
       </region>
      <region name="/aRegion">
      <attribute name="maxNodes">15000</attribute>
      <attribute name="timeToLiveSeconds">1000</attribute>
      </region>
       </config>
       </attribute>
      
       </mbean>
      
      </server>
      


      Many thanks for your help.

        • 1. Re: very strange behaviour of jboss cache 1.4.1
          brian.stansberry

          Please provide details of the AS version you are using and please confirm that you've configured EJB3 to use the org.jboss.ejb3.entity.TreeCacheProviderHook.

          Then are you calling flush() on your EntityManager as discussed on http://www.jboss.com/index.html?module=bb&op=viewtopic&t=148006 ?

          I haven't had a chance to follow up on that other thread, but am wondering if it is the same thing mihai.ratiu is seeing.

          • 2. Re: very strange behaviour of jboss cache 1.4.1
            bobbiee

            I am using JBoss 4.0.5, my persistence.xml looks like this:

            <persistence>
             <persistence-unit name="system-entities">
             <jta-data-source>java:/SystemDB</jta-data-source>
             <jar-file>../system-entities-1.0-SNAPSHOT.jar</jar-file>
             <properties>
             <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
             <property name="hibernate.hbm2ddl.auto" value="update"/>
             <property name="hibernate.show_sql" value="false"/>
             <property name="hibernate.cache.provider_class" value="org.jboss.ejb3.entity.TreeCacheProviderHook"/>
             <property name="hibernate.treecache.mbean.object_name" value="jboss.cache:service=EJB3EntityTreeCache"/>
             <property name="entity.manager.factory.jndi.name" value="java:/system-entities"/>
             </properties>
             </persistence-unit>
            </persistence>
            


            Thanks for the link, it seems like exactly the same problem like mihai.ratiu has, the same server version and the same cache version. I also use flush as I need entities to be saved into dbs while processing between different entity managers.

            However, this other topic is unfinished, mihai.ratiu is asking, if it could be flush, nobody answered so far...

            Could I try to not use flush? Will not I work with inconsistent data then??

            Thanks for your time.



            • 3. Re: very strange behaviour of jboss cache 1.4.1
              bobbiee

              Now after lots and lots of debugging I can confirm that the cache becomes empty after I user createNativeQuery() method of the EntityManager class. When I replace it by createQuery() method, cache looks like fine, without suddenly going to 0.

              Could this be the reason??

              • 4. Re: very strange behaviour of jboss cache 1.4.1
                brian.stansberry

                Yes, see comment I posted a half-hour or so ago on the other thread.

                If you execute native queries, Hibernate has no way to know what changes you are making in the underlying database, and is forced to aggressively clear the cache to avoid leaving stale data.

                Same thing applies if you do bulk updates -- i.e. update a bunch of entities that match a where clause -- since Hibernate doesn't know what entities match the where clause. So it is forced to remove all entities of the particular type from the cache.

                If you query for the entities that match your where clause and then iterate over them making the update one by one, Hibernate knows what entity instance was changed and can update the cache for just that one instance. Of course if your where clause matches a lot of entities, it might be more performant to accept losing the cache contents and do the bulk update.

                • 5. Re: very strange behaviour of jboss cache 1.4.1
                  bobbiee

                  Yes, that seems to be the problem:)

                  It looks like not good for me, cause I am working on project where is a lot of traffic. So some of the operations needs to use sql query to perform faster load (especially when loaded entities - huge objects are not ment to be cached) and in the same time, it's inadmissible for me to have clear cache so often, as the entities after are loaded directly from dbs and traffic is incredible, server is very unstable then...

                  Do you think I should switch the code to only use sql queries?? As ejb3 queries in cases the entities are not cached are slowing down the operations, especially the load.

                  • 6. Re: very strange behaviour of jboss cache 1.4.1
                    brian.stansberry

                    There's really no way to answer that question; whether caching is beneficial is highly dependent on the details of the application. I always encourage users to load test and benchmark; try different combinations to see what works best.

                    You say "it's inadmissible for me to have clear cache so often, as the entities after are loaded directly from dbs and traffic is incredible, server is very unstable then" so it sounds like you need a solution that avoids invalidating the cache. So is there anything you can do about the fact that "ejb3 queries in cases the entities are not cached are slowing down the operations, especially the load"? Are you annotating properties that don't have to be loaded with @java.persistence.Basic(fetch=LAZY)?

                    • 7. Re: very strange behaviour of jboss cache 1.4.1
                      bobbiee

                      I will try different combinations as you said. Anyway, thanks for helping me find out what is wrong, now its only to find some kind of middle way:)

                      Many thanks to you, bstansberry:)