6 Replies Latest reply on Jun 29, 2005 8:52 PM by Niel Bornstein

    Stack Overflow when using Collection classes in TreeCacheAop

    Andrew May Newbie

      I'm using JBoss 4.0.1 on Linux with JDK1.5 (also 1.4.2 which has same problem), and I'm getting a stack overflow when I call putObject for a class that has a Collection field.

      java.lang.StackOverflowError
      at javassist.ClassPool.toClass(ClassPool.java:713)
      at org.jboss.aop.deployment.JBossClassPool.toClass(JBossClassPool.java:50)
      at javassist.ClassPool.toClass(ClassPool.java:713)
      ...


      This is the test class I've been using:
      public class FakeSession implements Serializable
      {
       private Id sessionId;
       private Date created;
       private Set identities;
      
       public FakeSession(Id sessionId, Date created)
       {
       this.sessionId = sessionId;
       this.created = created;
       this.identities = new HashSet();
       }
      
       public Id getId()
       {
       return sessionId;
       }
      
       public Date getCreated()
       {
       return created;
       }
      
       public Set getIdentities()
       {
       return identities;
       }
      
       public void setIdentities(Set identities)
       {
       this.identities = identities;
       }
      
       public boolean equals(Object other)
       {
       return (other instanceof FakeSession && ((FakeSession)other).getId().equals(sessionId));
       }
      
       public int hashCode()
       {
       return sessionId.hashCode();
       }
      }
      


      If the identities field is null this can be put in the cache OK, but even an empty collection as shown here causes an overflow.

      The FakeSession and IdImpl (implements Id) have been processed with AopC:

      <aop>
       <prepare expr="field(* $instanceof{com.ingenta.ics.item.IdImpl}->*)" />
       <prepare expr="field(* $instanceof{com.ingenta.ics.session.FakeSession}->*)" />
      </aop>


      and this is the configuration for the cache (note: I intend to run this on a cluster of servers, but at the moment I'm running a single node):

      <server>
      
       <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
      
      
       <!-- ==================================================================== -->
       <!-- Defines TreeCache configuration -->
       <!-- ==================================================================== -->
      
       <mbean code="org.jboss.cache.aop.TreeCacheAop"
       name="jboss.cache:service=TreeCacheAop">
      
       <depends>jboss:service=Naming</depends>
       <depends>jboss:service=TransactionManager</depends>
      
       <attribute name="JndiName">java:/TreeCacheAop</attribute>
      
       <!--
       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>
      
       <!-- 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">TreeCacheAop-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 -->
       <!-- 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="224.0.0.1" 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"/>
       <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="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.AopLRUPolicy</attribute> -->
       <!-- Specific eviction policy configurations. This is LRU -->
       <!--
       <attribute name="EvictionPolicyConfig">
       <config>
       <attribute name="wakeUpIntervalSeconds">5</attribute>
       <region name="/_default_">
       <attribute name="maxNodes">5000</attribute>
       <attribute name="timeToIdleSeconds">1000</attribute>
       </region>
       <region name="/license">
       <attribute name="maxNodes">10000</attribute>
       <attribute name="timeToIdleSeconds">100000</attribute>
       </region>
       <region name="/session">
       <attribute name="maxNodes">10000</attribute>
       <attribute name="timeToIdleSeconds">100000</attribute>
       </region>
       </config>
       </attribute>
       -->
       </mbean>
      
       <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">
       <depends>jboss.cache:service=TreeCacheAop</depends>
       <attribute name="CacheService">jboss.cache:service=TreeCacheAop</attribute>
       </mbean>
      
      </server>
      


      Is there anything I'm doing that's obviously wrong?

      Thanks,
      Andrew

        • 1. Re: Stack Overflow when using Collection classes in TreeCach
          Andrew May Newbie

          I've managed to get a more useful portion of the stack trace using a debugger:

          Thread [http-0.0.0.0-7001-Processor25] (Suspended (exception java.lang.StackOverflowError))
           org.jboss.aop.deployment.JBossClassPool(javassist.ClassPool).toClass(javassist.CtClass) line: 713
           ...
           org.jboss.aop.deployment.JBossClassPool.toClass(javassist.CtClass, java.lang.ClassLoader) line: 50
           org.jboss.aop.deployment.JBossClassPool(javassist.ClassPool).toClass(javassist.CtClass) line: 713
           org.jboss.aop.deployment.JBossClassPool.toClass(javassist.CtClass, java.lang.ClassLoader) line: 50
           org.jboss.aop.deployment.JBossClassPool(javassist.ClassPool).toClass(javassist.CtClass) line: 713
           org.jboss.aop.deployment.JBossClassPool.toClass(javassist.CtClass, java.lang.ClassLoader) line: 50
           javassist.CtNewClass(javassist.CtClass).toClass() line: 1000
           org.jboss.aop.proxy.ClassProxyFactory.generateProxy(java.lang.Class) line: 138
           org.jboss.aop.proxy.ClassProxyFactory.newInstance(java.lang.Class) line: 52
           org.jboss.cache.aop.CollectionInterceptorUtil.getMethodMap(java.lang.Class) line: 50
           org.jboss.cache.aop.CachedSetInterceptor.<init>(org.jboss.cache.aop.TreeCacheAop, org.jboss.cache.Fqn, java.lang.Class) line: 41
           org.jboss.cache.aop.TreeCacheAop._putObject(org.jboss.cache.Fqn, java.lang.Object) line: 372
           org.jboss.cache.aop.TreeCacheAop._putObject(org.jboss.cache.Fqn, java.lang.Object) line: 265
           org.jboss.cache.aop.TreeCacheAop.putObject(org.jboss.cache.Fqn, java.lang.Object) line: 130
           com.ingenta.ics.session.SessionManagerBean.store(com.ingenta.ics.session.Session) line: 122
           com.ingenta.ics.session.SessionManagerBean.createSession() line: 104


          • 2. Re: Stack Overflow when using Collection classes in TreeCach
            Ben Wang Master

            Andrew,

            Looks like there is a loop during JBossAop trying to generate a proxy for the Set class.

            Can you go to jira.jboss.com and open a "bug" again jboss cache and assign it to me?

            It'd be best if you already have a JUnit testing set up so I can re-produce this. But if you don't please attach the xml, IdImpl, FakeSession, and you sample driver program.

            Thanks,

            -Ben

            • 3. Re: Stack Overflow when using Collection classes in TreeCach
              Andrew May Newbie

              Ben,

              I've raised http://jira.jboss.com/jira/browse/JBCACHE-37. It's been automatically assigned to Bela Ban, and I'm not sure whether I have permission to re-assign it. I've attached a simple test case that doesn't depend on any of our other code that reproduces the problem (for me at least).

              -Andrew

              • 4. Re: Stack Overflow when using Collection classes in TreeCach
                Ben Wang Master

                OK, I have assigned it to me.

                Thanks,

                -Ben

                • 5. Re: Stack Overflow when using Collection classes in TreeCach
                  Niel Bornstein Newbie

                  I am seeing a very similar problem with TreeCacheAop in JBoss 4.0.1sp1. I am trying to put a java.util.List in the cache and get a StackOverflowError. Could there be a regression in 4.0.1sp1?

                  • 6. Re: Stack Overflow when using Collection classes in TreeCach
                    Niel Bornstein Newbie

                     

                    "nbornstein" wrote:
                    I am seeing a very similar problem with TreeCacheAop in JBoss 4.0.1sp1. I am trying to put a java.util.List in the cache and get a StackOverflowError. Could there be a regression in 4.0.1sp1?


                    Never mind, I just reread the version number details this applies to.