My appologies. By 500K child nodes, I meant that this was a root, and that the sum of the descendants were 500K. xxx/yyy has 5 children.
Most nodes have a small number (<20) of children. Part of the testing was to see how I needed to change the data structure so that I minimized the number of child nodes :) One of xxx/yyy's children was a failed experiment with 1000 children. Thanks for the answer I am very reassured: I can delete my failed experiment nodes and I should be back working again. I'll tweak the default number any way. So is there a quick way of deleting a node which has hundred's of thousands of descendants? Clicking delete in explorer causes a crash. I can write a program to delete, but I suspect people have been here before? On Wed, Oct 19, 2011 at 9:19 PM, Justin Edelson <[email protected]> wrote: > Correction - the default maximum is 200, not 1000. Not sure what I was > looking at there. > > Justin > > On Wed, Oct 19, 2011 at 4:18 PM, Justin Edelson > <[email protected]> wrote: >> Phil- >> If the JSON object requested contains more than the maximum number of >> nodes, an array is returned indicating which requests can be made to >> return fewer than the max number of nodes. >> >> The typical use case for this is where /xxx contains /xxx/yy0 through >> /yy9 and each of /xxx/yy0 through /xxx/yy9 contains 100+ child nodes. >> If you requested /xxx.infinity.json, the result would contain 1012 >> nodes (if I'm doing the math right here). If that's more than the >> allowed maximum, you'd get back ['/xxx.0.json', /xxx.1.json'] meaning >> that either of those are requests which will be under the limit. >> >> This is a "feature" - http://issues.apache.org/jira/browse/SLING-1308 >> >> In your case, if you really mean to say that you have 500k child nodes >> under a single parent, you really should address this as that's not >> going to be good for performance across the board. >> >> The maximum node count can be increased through the configuration of >> the Default Get Servlet. The default is 1000. >> >> HTH, >> Justin >> >> On Wed, Oct 19, 2011 at 3:24 PM, Phil Rice <[email protected]> wrote: >>> I have a version of sling running that now has between 250K and 500K >>> nodes underneath a node called "/xxx/yyy". >>> >>> When I do a get to http://<host>/xxx/yyy/anything.1.json I get a >>> result that looks like: >>> {"jcr:primaryType":"nt:unstructured","artifact":{"jcr:primaryType":"nt:unstructured"}} >>> >>> In this case artifact is the name of a node under /xxx/yyy/anything. >>> As stated there are a lot of nodes under /xxx/yyy and my tests >>> indicate that all of them return a Json map, and as far as I can tell >>> the data matches the properties of the nodes. >>> >>> When I do a get to http://<host>/xxx/yyy.1.json I get a strange result >>> back: ["xxx/yyy.0.json"] >>> >>> When I do a get to http://<host>/xxx.1.json, I get the normal map. >>> >>> So of my half a million nodes, only this one is unusual. The nodes >>> above it behave correctly, the nodes below it behave correctly. Only >>> this one is strange. >>> >>> When I inspect the node /xxx/yyy with the explorer, it has only the >>> default jcr:primaryType property. >>> >>> As further information the response to http://<host>/xxx/yyy.0.json >>> return a map: {"jcr:primaryType":"nt:unstructured"} >>> >>> >>> >>> What is even more disturbing is that while I was testing it, initially >>> xxx/yyy.1.json behaved as normal, but about 2 days into the testing it >>> changed. I have been able to reproduce this, although with a cycle >>> time of many hours, it is hard to be certain what actions caused the >>> behavior to change. >>> >>> I would appreciate any advice on: >>> * What the result: ["xxx/yyy.0.json"] actually means >>> * Is this a bug, or is it a "feature" that I need to know about >>> >>> As this is on a server running live on the internet, I can pass ip >>> address/port details and username/password details in private emails >>> but I am loath to do that over an open email. >>> >> >
