jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Marginian <da...@butterdev.com>
Subject Re: Node Retrieval Performance
Date Sat, 14 Nov 2015 19:23:33 GMT
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 <wclayf@gmail.com> 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

View raw message