jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-548) Moving larger trees cause OutOfMemoryError
Date Mon, 14 Jan 2013 09:58:13 GMT

    [ https://issues.apache.org/jira/browse/OAK-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552541#comment-13552541
] 

Thomas Mueller commented on OAK-548:
------------------------------------

The diff method that results in a very large string is:

mk0.diff("0000000000000450", "0000000000000455", "/tree-b", 0);

So depth is 0 in this case. I wonder if MicroKernel.diff should really return such a large
result, or if it should only return a short string with the direct child nodes. According
to the MicroKernel contract:

depth 0: changes affecting the properties and child node names of the node at path

So I wonder if it's a bug in the MicroKernel implementation that causes such a large diff?
                
> Moving larger trees cause OutOfMemoryError
> ------------------------------------------
>
>                 Key: OAK-548
>                 URL: https://issues.apache.org/jira/browse/OAK-548
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>            Reporter: Michael Dürig
>
> {{LargeMoveTest.moveTest}} test runs out of heap space when moving roughly 100000 nodes
(128M heap):
> {code}
> java.lang.OutOfMemoryError: Java heap space
> 	at java.util.Arrays.copyOf(Arrays.java:2786)
> 	at java.lang.StringCoding.safeTrim(StringCoding.java:64)
> 	at java.lang.StringCoding.access$300(StringCoding.java:34)
> 	at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:251)
> 	at java.lang.StringCoding.encode(StringCoding.java:272)
> 	at java.lang.String.getBytes(String.java:946)
> 	at org.apache.jackrabbit.mk.util.IOUtils.writeString(IOUtils.java:84)
> 	at org.apache.jackrabbit.mk.store.BinaryBinding.writeMap(BinaryBinding.java:98)
> 	at org.apache.jackrabbit.mk.model.ChildNodeEntriesMap.serialize(ChildNodeEntriesMap.java:196)
> 	at org.apache.jackrabbit.mk.model.AbstractNode.serialize(AbstractNode.java:169)
> 	at org.apache.jackrabbit.mk.persistence.InMemPersistence.writeNode(InMemPersistence.java:76)
> 	at org.apache.jackrabbit.mk.store.DefaultRevisionStore.putNode(DefaultRevisionStore.java:276)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:568)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree$StagedNode.persist(StagedNodeTree.java:563)
> 	at org.apache.jackrabbit.mk.model.StagedNodeTree.persist(StagedNodeTree.java:80)
> 	at org.apache.jackrabbit.mk.model.CommitBuilder.doCommit(CommitBuilder.java:126)
> 	at org.apache.jackrabbit.mk.model.CommitBuilder.doCommit(CommitBuilder.java:94)
> 	at org.apache.jackrabbit.mk.core.MicroKernelImpl.commit(MicroKernelImpl.java:496)
> 	at org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.commit(KernelNodeStoreBranch.java:178)
> 	at org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.setRoot(KernelNodeStoreBranch.java:78)
> 	at org.apache.jackrabbit.oak.core.RootImpl.purgePendingChanges(RootImpl.java:355)
> 	at org.apache.jackrabbit.oak.core.RootImpl.commit(RootImpl.java:234)
> 	at org.apache.jackrabbit.oak.core.LargeMoveTest.moveTest(LargeMoveTest.java:78)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> {code}
> This is caused by the inefficient rebase implementation in oak-core as discussed at length
in OAK-464.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message