Thanks Robert. I considered moving to Oak, but the system was
originally designed using JackRabbit and I recently discovered this
limitation doing load/performance testing for a future requirement.
Moving to Oak now would be too large of a change for us to take on now.
Back to JackRabbit, is there documentation somewhere on the different
node types and which are ordered or not? I don't need ordered nodes but
I can't find documentation talking about the nodes and which are ordered
(currently using nt:folder).
On 11/14/2015 12:17 PM, Robert Munteanu wrote:
Hi Clay,
On Sat, Nov 14, 2015 at 5:46 PM, Clay Ferguson <[email protected]> wrote:
Robert, I don't think any of us, including myself, had a misunderstanding
about the fact that the limitation is for a large number of child nodes
under SAME parent. No one said 50K in the entire repository was causing
problems, but 50K children under same parent IS a problem if it's slow.
It's a very significant issue for actual application developers trying to
build something, because everything looks like its performing great but
will fail miserably when you scale it up. It's hard to call JCR 'enterprise
scale' with such a silly limitation staring is all right in the face
defying any solution.
That may or may not be true - the original post said that 'after 50K
plus child nodes retrieval is taking ~15 seconds'. I obviously added a
note that this - with the current JCR implementations - is expected.
What you consider a limitation is something that I personally consider
an implementation constraint - if you want to use JCR it's something
that you need to take into account.
That being said, Oak is expected to perform much better with flat
hierarchies, as long as the child nodes are not sortable. So you might
want to try this as well. Just be careful since nt:unstructured does
have orderable child nodes so you're better off using something like
oak:unstructured.
Thanks,
Robert
