[jira] [Updated] (OAK-7194) Threads are going in blocked state - OAK segment
[
https://issues.apache.org/jira/browse/OAK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kshitiz Garg updated OAK-7194:
--
Summary: Threads are going in blocked state - OAK segment (was: Threads
are going in blocked state)
> Threads are going in blocked state - OAK segment
>
>
> Key: OAK-7194
> URL: https://issues.apache.org/jira/browse/OAK-7194
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.6.2
>Reporter: Kshitiz Garg
>Priority: Critical
>
> We are using AEM and it internally is using OAK 1.6.2. Our application is
> going to a choked state many a times. Our thread dump analysis is always
> pointing to this stack trace with many blocked threads. Is it a known issue?
> Or is there a setting to avoid it? We are using tar files based repository
> underneath and are using default settings:
>
> {noformat}
> - nativeId:0x1208 - state:BLOCKED
> stackTrace:
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:121)
> - waiting to lock <0x000414d8c250> (a
> org.apache.jackrabbit.oak.segment.SegmentId)
> at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:412)
> at
> org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.createChild(ImmutableTree.java:125)
> at
> org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:176)
> at
> org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:81)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionUtil.getPrincipalRoot(PermissionUtil.java:83)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getPrincipalRoot(PermissionStoreImpl.java:132)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getNumEntries(PermissionStoreImpl.java:103)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryCache.getNumEntries(PermissionEntryCache.java:102)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.init(PermissionEntryProviderImpl.java:79)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.(PermissionEntryProviderImpl.java:72)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.(CompiledPermissionImpl.java:112)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.create(CompiledPermissionImpl.java:126)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getCompiledPermissions(PermissionProviderImpl.java:162)
> at
> org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getTreePermission(PermissionProviderImpl.java:151)
> at
> org.apache.jackrabbit.oak.security.authorization.composite.CompositeTreePermission.create(CompositeTreePermission.java:67)
> at
> org.apache.jackrabbit.oak.security.authorization.composite.CompositePermissionProvider.getTreePermission(CompositePermissionProvider.java:147)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:357)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.access$100(SecureNodeBuilder.java:49)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder$ReadablePropertyPredicate.apply(SecureNodeBuilder.java:377)
> at
> org.apache.jackrabbit.oak.core.SecureNodeBuilder.getProperty(SecureNodeBuilder.java:184)
> at
> org.apache.jackrabbit.oak.plugins.tree.impl.AbstractTree.getProperty(AbstractTree.java:249)
> at
> org.apache.jackrabbit.oak.core.MutableTree.getProperty(MutableTree.java:128)
> at
> org.apache.jackrabbit.oak.util.TreeUtil.getStringInternal(TreeUtil.java:108)
> at org.apache.jackrabbit.oak.util.TreeUtil.getString(TreeUtil.java:101)
> at
> org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getNamespacesProperty(GlobalNameMapper.java:191)
> at
> org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getOakURIOrNull(GlobalNameMapper.java:187)
> - eliminated <0x00070c692f50> (a
>
[jira] [Commented] (OAK-7183) Update Oak trunk to Jackrabbit 2.17.1
[ https://issues.apache.org/jira/browse/OAK-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336027#comment-16336027 ] Alex Deparvu commented on OAK-7183: --- I would need JCR-4249, to unblock some of the work needed on the Oak side. > Update Oak trunk to Jackrabbit 2.17.1 > - > > Key: OAK-7183 > URL: https://issues.apache.org/jira/browse/OAK-7183 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7194) Threads are going in blocked state
[
https://issues.apache.org/jira/browse/OAK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kshitiz Garg updated OAK-7194:
--
Description:
We are using AEM and it internally is using OAK 1.6.2. Our application is going
to a choked state many a times. Our thread dump analysis is always pointing to
this stack trace with many blocked threads. Is it a known issue? Or is there a
setting to avoid it? We are using tar files based repository underneath and are
using default settings:
{noformat}
- nativeId:0x1208 - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:121)
- waiting to lock <0x000414d8c250> (a
org.apache.jackrabbit.oak.segment.SegmentId)
at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:412)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.createChild(ImmutableTree.java:125)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:176)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:81)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionUtil.getPrincipalRoot(PermissionUtil.java:83)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getPrincipalRoot(PermissionStoreImpl.java:132)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getNumEntries(PermissionStoreImpl.java:103)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryCache.getNumEntries(PermissionEntryCache.java:102)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.init(PermissionEntryProviderImpl.java:79)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.(PermissionEntryProviderImpl.java:72)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.(CompiledPermissionImpl.java:112)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.create(CompiledPermissionImpl.java:126)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getCompiledPermissions(PermissionProviderImpl.java:162)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getTreePermission(PermissionProviderImpl.java:151)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositeTreePermission.create(CompositeTreePermission.java:67)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositePermissionProvider.getTreePermission(CompositePermissionProvider.java:147)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:357)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.access$100(SecureNodeBuilder.java:49)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder$ReadablePropertyPredicate.apply(SecureNodeBuilder.java:377)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getProperty(SecureNodeBuilder.java:184)
at
org.apache.jackrabbit.oak.plugins.tree.impl.AbstractTree.getProperty(AbstractTree.java:249)
at org.apache.jackrabbit.oak.core.MutableTree.getProperty(MutableTree.java:128)
at org.apache.jackrabbit.oak.util.TreeUtil.getStringInternal(TreeUtil.java:108)
at org.apache.jackrabbit.oak.util.TreeUtil.getString(TreeUtil.java:101)
at
org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getNamespacesProperty(GlobalNameMapper.java:191)
at
org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getOakURIOrNull(GlobalNameMapper.java:187)
- eliminated <0x00070c692f50> (a
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces)
at
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces.getNamespaceURI(SessionNamespaces.java:128)
- locked <0x00070c692f50> (a
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getNamespaceURI(SessionImpl.java:738)
at
com.adobe.granite.repository.impl.CRX3SessionImpl.getNamespaceURI(CRX3SessionImpl.java:283)
at
org.apache.sling.resourceresolver.impl.JcrNamespaceMangler.unmangleNamespaces(JcrNamespaceMangler.java:97)
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.unmangleNamespaces(ResourceResolverImpl.java:1109)
at
[jira] [Created] (OAK-7194) Threads are going in blocked state
Kshitiz Garg created OAK-7194:
-
Summary: Threads are going in blocked state
Key: OAK-7194
URL: https://issues.apache.org/jira/browse/OAK-7194
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: 1.6.2
Reporter: Kshitiz Garg
We are using AEM and it internally is using OAK 1.6.2. Our application is going
to a choked state many a times. Our thread dump analysis is always pointing to
this stack trace with many blocked threads. Is it a known issue? Or is there a
setting to avoid it? We are using tar files based repository underneath:
{noformat}
- nativeId:0x1208 - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:121)
- waiting to lock <0x000414d8c250> (a
org.apache.jackrabbit.oak.segment.SegmentId)
at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:192)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:412)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.createChild(ImmutableTree.java:125)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:176)
at
org.apache.jackrabbit.oak.plugins.tree.impl.ImmutableTree.getChild(ImmutableTree.java:81)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionUtil.getPrincipalRoot(PermissionUtil.java:83)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getPrincipalRoot(PermissionStoreImpl.java:132)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionStoreImpl.getNumEntries(PermissionStoreImpl.java:103)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryCache.getNumEntries(PermissionEntryCache.java:102)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.init(PermissionEntryProviderImpl.java:79)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionEntryProviderImpl.(PermissionEntryProviderImpl.java:72)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.(CompiledPermissionImpl.java:112)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.create(CompiledPermissionImpl.java:126)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getCompiledPermissions(PermissionProviderImpl.java:162)
at
org.apache.jackrabbit.oak.security.authorization.permission.PermissionProviderImpl.getTreePermission(PermissionProviderImpl.java:151)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositeTreePermission.create(CompositeTreePermission.java:67)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositePermissionProvider.getTreePermission(CompositePermissionProvider.java:147)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:357)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:360)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.access$100(SecureNodeBuilder.java:49)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder$ReadablePropertyPredicate.apply(SecureNodeBuilder.java:377)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getProperty(SecureNodeBuilder.java:184)
at
org.apache.jackrabbit.oak.plugins.tree.impl.AbstractTree.getProperty(AbstractTree.java:249)
at org.apache.jackrabbit.oak.core.MutableTree.getProperty(MutableTree.java:128)
at org.apache.jackrabbit.oak.util.TreeUtil.getStringInternal(TreeUtil.java:108)
at org.apache.jackrabbit.oak.util.TreeUtil.getString(TreeUtil.java:101)
at
org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getNamespacesProperty(GlobalNameMapper.java:191)
at
org.apache.jackrabbit.oak.namepath.GlobalNameMapper.getOakURIOrNull(GlobalNameMapper.java:187)
- eliminated <0x00070c692f50> (a
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces)
at
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces.getNamespaceURI(SessionNamespaces.java:128)
- locked <0x00070c692f50> (a
org.apache.jackrabbit.oak.jcr.session.SessionNamespaces)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getNamespaceURI(SessionImpl.java:738)
at
com.adobe.granite.repository.impl.CRX3SessionImpl.getNamespaceURI(CRX3SessionImpl.java:283)
at
[jira] [Commented] (OAK-5506) reject node names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335944#comment-16335944
]
Julian Reschke commented on OAK-5506:
-
The current patch is insufficient; we also need a check in
{{Namespaces.isValidLocalName()}}.
> reject node names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch,
> OAK-5506-name-conversion.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5506) reject node names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5506:
Labels: (was: patch-available)
> reject node names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch,
> OAK-5506-name-conversion.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7183) Update Oak trunk to Jackrabbit 2.17.1
[ https://issues.apache.org/jira/browse/OAK-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335805#comment-16335805 ] Julian Reschke commented on OAK-7183: - We'll update when it's ready :). > Update Oak trunk to Jackrabbit 2.17.1 > - > > Key: OAK-7183 > URL: https://issues.apache.org/jira/browse/OAK-7183 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7183) Update Oak trunk to Jackrabbit 2.17.1
[ https://issues.apache.org/jira/browse/OAK-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7183: Fix Version/s: (was: 1.9.0) > Update Oak trunk to Jackrabbit 2.17.1 > - > > Key: OAK-7183 > URL: https://issues.apache.org/jira/browse/OAK-7183 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7183) Update Oak trunk to Jackrabbit 2.17.1
[ https://issues.apache.org/jira/browse/OAK-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335778#comment-16335778 ] Davide Giannella commented on OAK-7183: --- Didn't actually check. Do we have anything in JR that requires us to update trunk? Otherwise I would wait for the first thing we need to take from JR for the actual update. > Update Oak trunk to Jackrabbit 2.17.1 > - > > Key: OAK-7183 > URL: https://issues.apache.org/jira/browse/OAK-7183 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.9.0, 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7183) Update Oak trunk to Jackrabbit 2.17.1
[ https://issues.apache.org/jira/browse/OAK-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7183: -- Fix Version/s: 1.10 1.9.0 > Update Oak trunk to Jackrabbit 2.17.1 > - > > Key: OAK-7183 > URL: https://issues.apache.org/jira/browse/OAK-7183 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.9.0, 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-7167) 1.0: oak-lucene uses packages from oak-core that are not exported
[ https://issues.apache.org/jira/browse/OAK-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke closed OAK-7167. --- > 1.0: oak-lucene uses packages from oak-core that are not exported > - > > Key: OAK-7167 > URL: https://issues.apache.org/jira/browse/OAK-7167 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.0.40 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.0.41 > > > See comments in https://issues.apache.org/jira/browse/OAK-5299. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-7170) Port OSGiIT.bundleStates() test back to 1.0
[ https://issues.apache.org/jira/browse/OAK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke closed OAK-7170. --- > Port OSGiIT.bundleStates() test back to 1.0 > --- > > Key: OAK-7170 > URL: https://issues.apache.org/jira/browse/OAK-7170 > Project: Jackrabbit Oak > Issue Type: Task > Components: it >Affects Versions: 1.0.40 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.0.41 > > > (this test was introduced for OAK-2402) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-4982) Enable bundling of some more nodetypes by default
[
https://issues.apache.org/jira/browse/OAK-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335688#comment-16335688
]
Marcel Reutegger commented on OAK-4982:
---
Other candidates:
- {{nt:versionHistory}}, which always has a {{jcr:rootVersion}} and
{{jcr:versionLabels}} child node.
- {{nt:version}} always has a single child node {{jcr:frozenNode}}
See attached [^OAK-4982.patch].
> Enable bundling of some more nodetypes by default
> -
>
> Key: OAK-4982
> URL: https://issues.apache.org/jira/browse/OAK-4982
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Attachments: OAK-4982.patch
>
>
> For OAK-4975 [~mreutegg] suggested to bundle few more nodetypes
> * rep:NodeType for JCR node types under /jcr:system/jcr:nodeTypes
> * rep:VersionStorage for intermediate version storage nodes under
> /jcr:system. We would probably have to limit it to one level. Each
> intermediate version storage node can have up to 255 child nodes.
> * oak:QueryIndexDefinition with one level that includes well known child
> nodes like: :data, :status, indexRules, :references, :weakreferences. Maybe
> include even more under indexRules?
> This issue is meant explore that
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4982) Enable bundling of some more nodetypes by default
[ https://issues.apache.org/jira/browse/OAK-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4982: -- Attachment: OAK-4982.patch > Enable bundling of some more nodetypes by default > - > > Key: OAK-4982 > URL: https://issues.apache.org/jira/browse/OAK-4982 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Attachments: OAK-4982.patch > > > For OAK-4975 [~mreutegg] suggested to bundle few more nodetypes > * rep:NodeType for JCR node types under /jcr:system/jcr:nodeTypes > * rep:VersionStorage for intermediate version storage nodes under > /jcr:system. We would probably have to limit it to one level. Each > intermediate version storage node can have up to 255 child nodes. > * oak:QueryIndexDefinition with one level that includes well known child > nodes like: :data, :status, indexRules, :references, :weakreferences. Maybe > include even more under indexRules? > This issue is meant explore that -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7186) avoid use of guava Iterators.emptyIterator()
[ https://issues.apache.org/jira/browse/OAK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335579#comment-16335579 ] Julian Reschke commented on OAK-7186: - trunk: [r1821983|http://svn.apache.org/r1821983] [r1821982|http://svn.apache.org/r1821982] [r1821981|http://svn.apache.org/r1821981] [r1821980|http://svn.apache.org/r1821980] [r1821979|http://svn.apache.org/r1821979] [r1821978|http://svn.apache.org/r1821978] [r1821977|http://svn.apache.org/r1821977] [r1821976|http://svn.apache.org/r1821976] [r1821975|http://svn.apache.org/r1821975] > avoid use of guava Iterators.emptyIterator() > > > Key: OAK-7186 > URL: https://issues.apache.org/jira/browse/OAK-7186 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_8 > Fix For: 1.9.0, 1.10 > > Attachments: OAK-7186.diff > > > Deprecated in Guava 19, removed in 20. > > [https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/Iterators.html#emptyIterator()] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7186) avoid use of guava Iterators.emptyIterator()
[ https://issues.apache.org/jira/browse/OAK-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-7186. - Resolution: Fixed Assignee: Julian Reschke Fix Version/s: 1.10 1.9.0 > avoid use of guava Iterators.emptyIterator() > > > Key: OAK-7186 > URL: https://issues.apache.org/jira/browse/OAK-7186 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Labels: candidate_oak_1_8 > Fix For: 1.9.0, 1.10 > > Attachments: OAK-7186.diff > > > Deprecated in Guava 19, removed in 20. > > [https://google.github.io/guava/releases/19.0/api/docs/com/google/common/collect/Iterators.html#emptyIterator()] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6254) DataStore: API to retrieve approximate storage size
[
https://issues.apache.org/jira/browse/OAK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335544#comment-16335544
]
Amit Jain commented on OAK-6254:
[~tmueller]
bq. Much faster would be to calculate the size during garbage collection.
Yes that is certainly feasible and the storage could be in the metadata space
in the datastore already being used for other things.
> DataStore: API to retrieve approximate storage size
> ---
>
> Key: OAK-6254
> URL: https://issues.apache.org/jira/browse/OAK-6254
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> The estimated size of the datastore (on disk) is needed to:
> * monitor growth over time, or growth of certain operations
> * monitor if garbage collection is effective
> * avoid out of disk space
> * estimate backup size
> * statistical purposes (for example, if there are many repositories, to group
> them by size)
> Datastore size: we could use the following heuristic: We could read the file
> sizes in ./datastore/00/00 (if it exists) and multiply by 65536; or
> ./datastore/00 and multiply by 256. That would give a rough estimation
> (within about 20% for repositories with datastore size > 50 GB).
> I think this is mainly important for the FileDataStore. The S3 datastore, if
> there is a simple and fast S3 API to read the size, then that would be good
> as well, but if there is none, then returning "unknown" is fine for me.
> As for the API, I would use something like this: {{long
> getEstimatedStorageSize(int accuracyLevel)}} with accuracyLevel 1 for
> inaccurate (fastest), 2 more accurate (slower),..., 9 precise (possibly very
> slow). Similar to
> [java.util.zip.Deflater.setLevel|https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#setLevel(int)].
> I would expect it takes up to 1 second for accuracyLevel 0, up to 5 seconds
> for accuracyLevel 1, and possibly hours for level 9. With level 1, I would
> read files in 00/00, with level 2 - 8 I would read files in 00, and with
> level 9 I would read all the files. For level 1, I wouldn't stop; for level
> 2, if it takes more than 5 seconds, I would stop and return the current best
> estimate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6254) DataStore: API to retrieve approximate storage size
[
https://issues.apache.org/jira/browse/OAK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335543#comment-16335543
]
Chetan Mehrotra commented on OAK-6254:
--
bq. The size could be stored in a file, and updated whenever datastore GC is
run.
It may be better to store the unstructured data in NodeStore itself under
specific node.
> DataStore: API to retrieve approximate storage size
> ---
>
> Key: OAK-6254
> URL: https://issues.apache.org/jira/browse/OAK-6254
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> The estimated size of the datastore (on disk) is needed to:
> * monitor growth over time, or growth of certain operations
> * monitor if garbage collection is effective
> * avoid out of disk space
> * estimate backup size
> * statistical purposes (for example, if there are many repositories, to group
> them by size)
> Datastore size: we could use the following heuristic: We could read the file
> sizes in ./datastore/00/00 (if it exists) and multiply by 65536; or
> ./datastore/00 and multiply by 256. That would give a rough estimation
> (within about 20% for repositories with datastore size > 50 GB).
> I think this is mainly important for the FileDataStore. The S3 datastore, if
> there is a simple and fast S3 API to read the size, then that would be good
> as well, but if there is none, then returning "unknown" is fine for me.
> As for the API, I would use something like this: {{long
> getEstimatedStorageSize(int accuracyLevel)}} with accuracyLevel 1 for
> inaccurate (fastest), 2 more accurate (slower),..., 9 precise (possibly very
> slow). Similar to
> [java.util.zip.Deflater.setLevel|https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#setLevel(int)].
> I would expect it takes up to 1 second for accuracyLevel 0, up to 5 seconds
> for accuracyLevel 1, and possibly hours for level 9. With level 1, I would
> read files in 00/00, with level 2 - 8 I would read files in 00, and with
> level 9 I would read all the files. For level 1, I wouldn't stop; for level
> 2, if it takes more than 5 seconds, I would stop and return the current best
> estimate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6254) DataStore: API to retrieve approximate storage size
[
https://issues.apache.org/jira/browse/OAK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335540#comment-16335540
]
Thomas Mueller commented on OAK-6254:
-
Much faster would be to calculate the size during garbage collection. [~amjain]
do you think it would be feasible? The size could be stored in a file, and
updated whenever datastore GC is run.
We could also store a histogram, for different file sizes, as follows (for each
size: total number of files, total file size): up to 2 KB, up to 16 KB, up to
128 KB, up to 1 MB, up to 8 MB,...
> DataStore: API to retrieve approximate storage size
> ---
>
> Key: OAK-6254
> URL: https://issues.apache.org/jira/browse/OAK-6254
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> The estimated size of the datastore (on disk) is needed to:
> * monitor growth over time, or growth of certain operations
> * monitor if garbage collection is effective
> * avoid out of disk space
> * estimate backup size
> * statistical purposes (for example, if there are many repositories, to group
> them by size)
> Datastore size: we could use the following heuristic: We could read the file
> sizes in ./datastore/00/00 (if it exists) and multiply by 65536; or
> ./datastore/00 and multiply by 256. That would give a rough estimation
> (within about 20% for repositories with datastore size > 50 GB).
> I think this is mainly important for the FileDataStore. The S3 datastore, if
> there is a simple and fast S3 API to read the size, then that would be good
> as well, but if there is none, then returning "unknown" is fine for me.
> As for the API, I would use something like this: {{long
> getEstimatedStorageSize(int accuracyLevel)}} with accuracyLevel 1 for
> inaccurate (fastest), 2 more accurate (slower),..., 9 precise (possibly very
> slow). Similar to
> [java.util.zip.Deflater.setLevel|https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#setLevel(int)].
> I would expect it takes up to 1 second for accuracyLevel 0, up to 5 seconds
> for accuracyLevel 1, and possibly hours for level 9. With level 1, I would
> read files in 00/00, with level 2 - 8 I would read files in 00, and with
> level 9 I would read all the files. For level 1, I wouldn't stop; for level
> 2, if it takes more than 5 seconds, I would stop and return the current best
> estimate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7193) DataStore: API to retrieve statistic (file headers, size estimation)
[
https://issues.apache.org/jira/browse/OAK-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-7193:
Fix Version/s: 1.10
> DataStore: API to retrieve statistic (file headers, size estimation)
>
>
> Key: OAK-7193
> URL: https://issues.apache.org/jira/browse/OAK-7193
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> Extension of OAK-6254: in addition to retrieving the size, it would be good
> to retrieve the estimated number and total size per file type. A simple (and
> in my view sufficient) solution is to use the first few bytes ("magic
> numbers", 2 bytes should be enough) to get the file type. That would allow to
> estimate, for example, the number of, and total size, of PDF files, JPEG,
> Lucene index and so on. A histogram would be nice as well, but I think is not
> needed.
> To speed up calculation, the blob ID could be extended with the first 2 bytes
> of the file content, that is: #@ where magic is the
> first two bytes, in hex. That would allow to quickly get the data from the
> blob ids (no need to actually read content).
> Sampling should be enough. The longer it takes, the more accurate the data.
> We could store the data while doing datastore GC, in which case the returned
> data would be somewhat stale; that's OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7193) DataStore: API to retrieve statistic (file headers, size estimation)
Thomas Mueller created OAK-7193:
---
Summary: DataStore: API to retrieve statistic (file headers, size
estimation)
Key: OAK-7193
URL: https://issues.apache.org/jira/browse/OAK-7193
Project: Jackrabbit Oak
Issue Type: Improvement
Components: blob
Reporter: Thomas Mueller
Extension of OAK-6254: in addition to retrieving the size, it would be good to
retrieve the estimated number and total size per file type. A simple (and in my
view sufficient) solution is to use the first few bytes ("magic numbers", 2
bytes should be enough) to get the file type. That would allow to estimate, for
example, the number of, and total size, of PDF files, JPEG, Lucene index and so
on. A histogram would be nice as well, but I think is not needed.
To speed up calculation, the blob ID could be extended with the first 2 bytes
of the file content, that is: #@ where magic is the first
two bytes, in hex. That would allow to quickly get the data from the blob ids
(no need to actually read content).
Sampling should be enough. The longer it takes, the more accurate the data. We
could store the data while doing datastore GC, in which case the returned data
would be somewhat stale; that's OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6254) DataStore: API to retrieve approximate storage size
[
https://issues.apache.org/jira/browse/OAK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-6254:
Fix Version/s: 1.10
> DataStore: API to retrieve approximate storage size
> ---
>
> Key: OAK-6254
> URL: https://issues.apache.org/jira/browse/OAK-6254
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.10
>
>
> The estimated size of the datastore (on disk) is needed to:
> * monitor growth over time, or growth of certain operations
> * monitor if garbage collection is effective
> * avoid out of disk space
> * estimate backup size
> * statistical purposes (for example, if there are many repositories, to group
> them by size)
> Datastore size: we could use the following heuristic: We could read the file
> sizes in ./datastore/00/00 (if it exists) and multiply by 65536; or
> ./datastore/00 and multiply by 256. That would give a rough estimation
> (within about 20% for repositories with datastore size > 50 GB).
> I think this is mainly important for the FileDataStore. The S3 datastore, if
> there is a simple and fast S3 API to read the size, then that would be good
> as well, but if there is none, then returning "unknown" is fine for me.
> As for the API, I would use something like this: {{long
> getEstimatedStorageSize(int accuracyLevel)}} with accuracyLevel 1 for
> inaccurate (fastest), 2 more accurate (slower),..., 9 precise (possibly very
> slow). Similar to
> [java.util.zip.Deflater.setLevel|https://docs.oracle.com/javase/7/docs/api/java/util/zip/Deflater.html#setLevel(int)].
> I would expect it takes up to 1 second for accuracyLevel 0, up to 5 seconds
> for accuracyLevel 1, and possibly hours for level 9. With level 1, I would
> read files in 00/00, with level 2 - 8 I would read files in 00, and with
> level 9 I would read all the files. For level 1, I wouldn't stop; for level
> 2, if it takes more than 5 seconds, I would stop and return the current best
> estimate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7192) Remove package export for org.apache.jackrabbit.oak.composite.checks
[
https://issues.apache.org/jira/browse/OAK-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-7192:
--
Summary: Remove package export for
org.apache.jackrabbit.oak.composite.checks (was: [RTC] Remove package export
for org.apache.jackrabbit.oak.composite.checks)
> Remove package export for org.apache.jackrabbit.oak.composite.checks
>
>
> Key: OAK-7192
> URL: https://issues.apache.org/jira/browse/OAK-7192
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.10
>
>
> It appears the package {{org.apache.jackrabbit.oak.composite.checks}} is only
> used internally by the oak-store-composite module and should not be exported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7192) [RTC] Remove package export for org.apache.jackrabbit.oak.composite.checks
[
https://issues.apache.org/jira/browse/OAK-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-7192:
--
Summary: [RTC] Remove package export for
org.apache.jackrabbit.oak.composite.checks (was: Remove package export for
org.apache.jackrabbit.oak.composite.checks)
> [RTC] Remove package export for org.apache.jackrabbit.oak.composite.checks
> --
>
> Key: OAK-7192
> URL: https://issues.apache.org/jira/browse/OAK-7192
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.10
>
>
> It appears the package {{org.apache.jackrabbit.oak.composite.checks}} is only
> used internally by the oak-store-composite module and should not be exported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7192) Remove package export for org.apache.jackrabbit.oak.composite.checks
Marcel Reutegger created OAK-7192:
-
Summary: Remove package export for
org.apache.jackrabbit.oak.composite.checks
Key: OAK-7192
URL: https://issues.apache.org/jira/browse/OAK-7192
Project: Jackrabbit Oak
Issue Type: Improvement
Components: composite
Reporter: Marcel Reutegger
Fix For: 1.10
It appears the package {{org.apache.jackrabbit.oak.composite.checks}} is only
used internally by the oak-store-composite module and should not be exported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
