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:
- Navigate to the content sync console URL: /libs/cq/contentsync/content/console.html
- Click on the 'Clear Cache' button.
- Click on the 'Update Cache' button. No problems up to here, content sync cache (under /var/contentsync) is populated with expected assets and files.
- 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(Ab stractReferenceMap.java:434)
at org.apache.commons.collections.map.AbstractHashedMap.getEntry(Abstrac tHashedMap.java:436)
at org.apache.commons.collections.map.AbstractReferenceMap.getEntry(Abst ractReferenceMap.java:405)
at org.apache.commons.collections.map.AbstractReferenceMap.get(AbstractR eferenceMap.java:230)
at org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(Ite mStateReferenceCache.java:147)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(L ocalItemStateManager.java:171)
at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAIt emStateManager.java:260)
at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState (SessionItemStateManager.java:161)
at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:3 82)
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(LazyItemIter ator.java:122)
at org.apache.jackrabbit.core.LazyItemIterator.<init>(LazyItemIterator.j ava:104)
at org.apache.jackrabbit.core.LazyItemIterator.<init>(LazyItemIterator.j ava: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