1 Reply Latest reply on May 3, 2013 2:44 PM by Sham HC

    Getting a StackOverflowError trying to download big content sync zip file

    Daniel Valencia Backhoff

      We've noticed this happens when trying to download a big Content Sync zip file (typically of around 280MB, although recently we saw the same issue with a 250MB file, so we're not sure of the root cause of this).

       

      The only prerequisite to reproduce this issue is to configure your content sync to have > 250MB of content (in the form of images, html, js, etc).  The steps to reproduce are the following:

      1. Navigate to the content sync console URL: /libs/cq/contentsync/content/console.html
      2. Click on the 'Clear Cache' button.
      3. Click on the 'Update Cache' button.  No problems up to here, content sync cache (under /var/contentsync) is populated with expected assets and files.
      4. Click on the 'Download Full' button.  Almost immediately, the app crashes with the following stack trace:

       

      02.05.2013 00:56:14.248 *ERROR* [204.90.11.3 [1367455869892] GET /etc/contentsync/audiusa-retail.zip HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught Throwable java.lang.StackOverflowError

              at org.apache.commons.collections.map.AbstractReferenceMap.isEqualKey(AbstractReferenceMap.j ava:434)

              at org.apache.commons.collections.map.AbstractHashedMap.getEntry(AbstractHashedMap.java:436)

              at org.apache.commons.collections.map.AbstractReferenceMap.getEntry(AbstractReferenceMap.jav a:405)

              at org.apache.commons.collections.map.AbstractReferenceMap.get(AbstractReferenceMap.java:230 )

              at org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(ItemStateReferenceCache .java:147)

              at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager .java:171)

              at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java: 260)

              at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateMan ager.java:161)

              at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)

              at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)

              at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)

              at org.apache.jackrabbit.core.LazyItemIterator.prefetchNext(LazyItemIterator.java:122)

              at org.apache.jackrabbit.core.LazyItemIterator.<init>(LazyItemIterator.java:104)

              at org.apache.jackrabbit.core.LazyItemIterator.<init>(LazyItemIterator.java:85)

              at org.apache.jackrabbit.core.ItemManager.getChildProperties(ItemManager.java:816)

              at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2178)

              at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2174)

              at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)

              at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)

              at org.apache.jackrabbit.core.NodeImpl.getProperties(NodeImpl.java:2174)

              at javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:202)

              at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1697)

              at javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:219)

              at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1697)

              at javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:219)

              at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1697)

              at javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:219)

              at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1697)

              at javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:219)

              ...


      We've extended the content sync framework by writing 2 ContentUpdateHandler implementations.  Given that the content update process finishes correctly, we dont' think this is the root cause of the problem.

       

      Any help on this subject is appreciated.

       

      Thanks,

      -Daniel