> Are you saying that forcing the read of all root children is an
> *unintended* effect of "builder.setProperty(JCR_PRIMARYTYPE, NT_REP_ROOT,
> Type.NAME);"?
>
> Is there anything that can be configured or overridden to combat this side
> effect?
Well, I didn't write a test to actually see this,
Thanks, Vikas.
Are you saying that forcing the read of all root children is an
*unintended* effect of "builder.setProperty(JCR_PRIMARYTYPE, NT_REP_ROOT,
Type.NAME);"?
Is there anything that can be configured or overridden to combat this side
effect?
On Tue, Feb 28, 2017 at 3:37 PM, Vikas
To me, the culprit seems like first line of
`org.apache.jackrabbit.oak.plugins.nodetype.write.InitialContent.initialize`:
builder.setProperty(JCR_PRIMARYTYPE, NT_REP_ROOT, Type.NAME);
which would the force
>org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.squeeze line:
> 125
to
Hi Chetan, sure. Below is the dump on startup. I highlighted in yellow the
place where it loops over existing nodes and spends all those minutes.
Thank you for any hits/feedback!
main [1] (RUNNABLE)
java.net.SocketInputStream.socketRead0 line: not available [native
method]
Can you provide a thread dump around startup time where you see Oak is
reading all child nodes?
Chetan Mehrotra
On Fri, Feb 24, 2017 at 2:26 AM, Eugene Prystupa
wrote:
> Thanks, Michael.
>
> I should have included more details in the original email.
> We are on 1.4.10
Thanks, Michael.
I should have included more details in the original email.
We are on 1.4.10 version of Jackrabbit Oak, we are using Mongo backend.
On Thu, Feb 23, 2017 at 3:40 PM, Michael Dürig wrote:
>
>
> On 23.02.17 19:11, Eugene Prystupa wrote:
>
>> We are seeing
On 23.02.17 19:11, Eugene Prystupa wrote:
We are seeing severe delays on start-up (20 minutes+) when repository is
created (new Jcr(oak).createRepository()).
Regardless of the content structure, 20 min. seems off. What back-end
are you on? Which version of Oak is this?
Michael
Hi Eugene,
There are 2 aspects here:
The repository definitely should not take such a long time for startup (or
presumably read all/many children of root at startup).
But the reason why this was not seen before pertains to your second question:
It is definitely not advised to store that many
Can anyone confirm if this is a viable storage option? We have an
Oak-backed repository with ~100,000 documents in it (and growing), and all
documents are stored as children nodes of the root node.
We are seeing severe delays on start-up (20 minutes+) when repository is
created (new