Back in November we had an out-of-memory problem with our Sling application. I determined that a periodic task was executing a query that appeared to be unlimited in terms of result set size, which would eat up memory as the repository grew. In order to combat this I marked the nodes I am interested in with a boolean flag, and I configured Jackrabbit to set the resultFetchSize to 100. This seemed to solve the problem and we had no further issues - until last week, when the problem reappeared.
I've been able to determine that the problem is entirely in the execution of this query. I can enter it from the JCR Explorer query window and it will cause the runaway memory problem. The query is very straightforward, it is simply: select * from [nt:base] where uploadToImageManagerFlag = true I have no need for any parallel results, I simply want to examine the resultant Resources one at a time. Deleting/rebuilding the Jackrabbit indexes did not help. Any ideas why this query might be causing runaway memory consumption? Looking at a heap dump it appears that there are massive numbers of NodeId, HashMap$Entry, NameSet, ChildNodeEntry, NodeState, etc. It seems that for whatever reason a large number of nodes are being pulled into memory. If this would make more sense on the Jackrabbit list I can ask over there as well. Thanks!
