[jira] [Created] (OAK-8211) Build Jackrabbit Oak #2076 failed
Hudson created OAK-8211: --- Summary: Build Jackrabbit Oak #2076 failed Key: OAK-8211 URL: https://issues.apache.org/jira/browse/OAK-8211 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2076 has failed. First failed run: [Jackrabbit Oak #2076|https://builds.apache.org/job/Jackrabbit%20Oak/2076/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2076/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8186) Create API in OAK for file access to binaries in the repository.
[
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813798#comment-16813798
]
Matt Ryan edited comment on OAK-8186 at 4/9/19 9:02 PM:
[~frm] I completely agree wrt direct access - as far as I'm concerned offering
direct access to the binary in the FileDataStore is not something we would
consider.
This proposal isn't about directly accessing any files in the data store. It's
about adding API to ask Oak to create a temporary file, a copy of a {{Binary}},
that *can* be accessed directly without harming Oak - because the temporary
file isn't part of the repo. The reason to have Oak do it instead of just
doing it through the JCR API would be for better efficiency.
Maybe I don't understand your concern? I'm not sure we are talking about the
same thing.
was (Author: mattvryan):
[~frm] I completely agree wrt direct access - as far as I'm concerned offering
direct access to the binary in the FileDataStore is not something we would
consider.
This proposal isn't about directly accessing any files in the data store. It's
about adding API to ask Oak to create a temporary file, a copy of a {{Binary}},
that *can* be accessed directly without harming Oak - because the temporary
file isn't part of the repo.
Maybe I don't understand your concern? I'm not sure we are talking about the
same thing.
> Create API in OAK for file access to binaries in the repository.
>
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg,
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It
> would be nice if an API existed to get file access directly from OAK. This
> might also meet some use cases documented at
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API
> makes it explicit that a temp file is created. I am not sure if direct access
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.
[
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813798#comment-16813798
]
Matt Ryan commented on OAK-8186:
[~frm] I completely agree wrt direct access - as far as I'm concerned offering
direct access to the binary in the FileDataStore is not something we would
consider.
This proposal isn't about directly accessing any files in the data store. It's
about adding API to ask Oak to create a temporary file, a copy of a {{Binary}},
that *can* be accessed directly without harming Oak - because the temporary
file isn't part of the repo.
Maybe I don't understand your concern? I'm not sure we are talking about the
same thing.
> Create API in OAK for file access to binaries in the repository.
>
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg,
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It
> would be nice if an API existed to get file access directly from OAK. This
> might also meet some use cases documented at
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API
> makes it explicit that a temp file is created. I am not sure if direct access
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8208) oak-run/rdb: add --rdbtableprefix option
[ https://issues.apache.org/jira/browse/OAK-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8208: Labels: candidate_oak_1_10 (was: ) > oak-run/rdb: add --rdbtableprefix option > > > Key: OAK-8208 > URL: https://issues.apache.org/jira/browse/OAK-8208 > Project: Jackrabbit Oak > Issue Type: Task > Components: rdbmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.14.0 > > Attachments: OAK-8208.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8208) oak-run/rdb: add --rdbtableprefix option
[ https://issues.apache.org/jira/browse/OAK-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813734#comment-16813734 ] Julian Reschke commented on OAK-8208: - trunk: [r1857221|http://svn.apache.org/r1857221] > oak-run/rdb: add --rdbtableprefix option > > > Key: OAK-8208 > URL: https://issues.apache.org/jira/browse/OAK-8208 > Project: Jackrabbit Oak > Issue Type: Task > Components: rdbmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.14.0 > > Attachments: OAK-8208.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8208) oak-run/rdb: add --rdbtableprefix option
[ https://issues.apache.org/jira/browse/OAK-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8208. - Resolution: Fixed > oak-run/rdb: add --rdbtableprefix option > > > Key: OAK-8208 > URL: https://issues.apache.org/jira/browse/OAK-8208 > Project: Jackrabbit Oak > Issue Type: Task > Components: rdbmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.14.0 > > Attachments: OAK-8208.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8210) Build Jackrabbit Oak #2074 failed
[ https://issues.apache.org/jira/browse/OAK-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813702#comment-16813702 ] Hudson commented on OAK-8210: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2075|https://builds.apache.org/job/Jackrabbit%20Oak/2075/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2075/console] > Build Jackrabbit Oak #2074 failed > - > > Key: OAK-8210 > URL: https://issues.apache.org/jira/browse/OAK-8210 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2074 has failed. > First failed run: [Jackrabbit Oak > #2074|https://builds.apache.org/job/Jackrabbit%20Oak/2074/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2074/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8210) Build Jackrabbit Oak #2074 failed
Hudson created OAK-8210: --- Summary: Build Jackrabbit Oak #2074 failed Key: OAK-8210 URL: https://issues.apache.org/jira/browse/OAK-8210 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2074 has failed. First failed run: [Jackrabbit Oak #2074|https://builds.apache.org/job/Jackrabbit%20Oak/2074/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2074/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813535#comment-16813535 ] Francesco Mari commented on OAK-6947: - I have no strong preference about the oak-store-spi module and the patch will probably being reworked, being more than a year old. Free for everyone to pick this up. > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Assignee: Francesco Mari >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8207) Read-only DocumentNodeStore tries to create root document
[
https://issues.apache.org/jira/browse/OAK-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-8207.
---
Resolution: Fixed
Fix Version/s: 1.14.0
Fixed in trunk: http://svn.apache.org/r1857212
Creating a read-only DocumentNodeStore on an empty nodes collection still fails
with an exception, but it doesn't try to create the root document anymore and
the exception is more descriptive now.
> Read-only DocumentNodeStore tries to create root document
> -
>
> Key: OAK-8207
> URL: https://issues.apache.org/jira/browse/OAK-8207
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> When connecting a read-only DocumentNodeStore to a DocumentStore with an
> empty {{nodes}} collection, the DocumentNodeStore tries to create the root
> document. The operation then fails with something like:
> {noformat}
> Exception in thread "main"
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Method -
> createOrUpdate. Params: [nodes, [key: 0:/ new
> {_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false,
> _commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.asDocumentStoreException(DocumentStoreException.java:179)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:131)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:114)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:425)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:280)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:264)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:624)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBuilder.build(DocumentNodeStoreBuilder.java:174)
> at
> org.apache.jackrabbit.oak.run.ClusterNodesCommand.execute(ClusterNodesCommand.java:65)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.UnsupportedOperationException: Method - createOrUpdate.
> Params: [nodes, [key: 0:/ new {_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false,
> _commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
> at
> org.apache.jackrabbit.oak.plugins.document.util.ReadOnlyDocumentStoreWrapperFactory$1.invoke(ReadOnlyDocumentStoreWrapperFactory.java:38)
> at com.sun.proxy.$Proxy0.createOrUpdate(Unknown Source)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:365)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari reassigned OAK-6947: --- Assignee: (was: Francesco Mari) > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813530#comment-16813530
]
Marcel Reutegger commented on OAK-8209:
---
Proposed changes are on GitHub:
https://github.com/apache/jackrabbit-oak/compare/trunk...mreutegg:OAK-8209
The changes on NodeImpl only have a minor impact but still prevent creating
objects unnecessarily. The more important change with more impact on
performance is in WorkspaceImpl. The ReadWriteNodeTypeManager now remembers the
Tree at {{/jcr:system/jcr:nodeTypes}}. I'm a bit rusty with the exact semantics
of Trees, but AFAIU this is fine because a Tree reflects changes that may
happen underneath. The Root from which the Tree was previously acquired on each
call is always the same. The root in SessionDelegate is final. That is, the
ReadWriteNodeTypeManager can just as well remember the Tree.
[~mduerig], could you have a quick look and let me know what you think?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-3316) BTreeManager doesn't work
[
https://issues.apache.org/jira/browse/OAK-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813513#comment-16813513
]
Michael Dürig commented on OAK-3316:
Unassigning myself as I don't have the capacity to work on this
> BTreeManager doesn't work
> -
>
> Key: OAK-3316
> URL: https://issues.apache.org/jira/browse/OAK-3316
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
> Environment: Adobe AEM 6.1
>Reporter: Sam Shao
>Priority: Major
>
> See my codes below. It fails on 41 node.
> Session session = req.getResourceResolver().adaptTo(Session.class);
> Node contentNode = session.getNode("/content");
> Node testNode = contentNode.hasNode("test1") ? contentNode.getNode("test1") :
> contentNode.addNode("test1");
> BTreeManager manager = new BTreeManager(testNode, 20, 40,
> Rank.comparableComparator(), true);
> NodeSequence nodes = ItemSequence.createNodeSequence(manager);
> for (int i = 0; i < 100; ++i) {
> String name = "Node" + String.format("%02d", (i + 1));
> writer.write("Creating node [" + name + "] ...");
> nodes.addNode(name, NodeType.NT_UNSTRUCTURED);
> writer.write(" Done.\n");
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-3316) BTreeManager doesn't work
[
https://issues.apache.org/jira/browse/OAK-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-3316:
--
Assignee: (was: Michael Dürig)
> BTreeManager doesn't work
> -
>
> Key: OAK-3316
> URL: https://issues.apache.org/jira/browse/OAK-3316
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.2
> Environment: Adobe AEM 6.1
>Reporter: Sam Shao
>Priority: Major
>
> See my codes below. It fails on 41 node.
> Session session = req.getResourceResolver().adaptTo(Session.class);
> Node contentNode = session.getNode("/content");
> Node testNode = contentNode.hasNode("test1") ? contentNode.getNode("test1") :
> contentNode.addNode("test1");
> BTreeManager manager = new BTreeManager(testNode, 20, 40,
> Rank.comparableComparator(), true);
> NodeSequence nodes = ItemSequence.createNodeSequence(manager);
> for (int i = 0; i < 100; ++i) {
> String name = "Node" + String.format("%02d", (i + 1));
> writer.write("Creating node [" + name + "] ...");
> nodes.addNode(name, NodeType.NT_UNSTRUCTURED);
> writer.write(" Done.\n");
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-1576) SegmentMK: Implement refined conflict resolution for addExistingNode conflicts
[ https://issues.apache.org/jira/browse/OAK-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813512#comment-16813512 ] Michael Dürig commented on OAK-1576: Unassigning myself as there is no plans for addressing anytime soon. > SegmentMK: Implement refined conflict resolution for addExistingNode conflicts > -- > > Key: OAK-1576 > URL: https://issues.apache.org/jira/browse/OAK-1576 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segment-tar >Reporter: Michael Dürig >Priority: Major > Labels: concurrency, resilience, scalability, technical_debt > > Implement refined conflict resolution for addExistingNode conflicts as > defined in the parent issue for the SegementMK. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-1553:
--
Assignee: (was: Michael Dürig)
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk, segment-tar
>Reporter: Michael Dürig
>Priority: Major
> Labels: concurrency, scalability, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813510#comment-16813510
]
Michael Dürig commented on OAK-1553:
Unassigning myself as there is no plan to resolve this anytime soon.
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk, segment-tar
>Reporter: Michael Dürig
>Priority: Major
> Labels: concurrency, scalability, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-1576) SegmentMK: Implement refined conflict resolution for addExistingNode conflicts
[ https://issues.apache.org/jira/browse/OAK-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-1576: -- Assignee: (was: Michael Dürig) > SegmentMK: Implement refined conflict resolution for addExistingNode conflicts > -- > > Key: OAK-1576 > URL: https://issues.apache.org/jira/browse/OAK-1576 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segment-tar >Reporter: Michael Dürig >Priority: Major > Labels: concurrency, resilience, scalability, technical_debt > > Implement refined conflict resolution for addExistingNode conflicts as > defined in the parent issue for the SegementMK. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-4689) Add information about amount of data vs. waste to oak-run
[
https://issues.apache.org/jira/browse/OAK-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813508#comment-16813508
]
Michael Dürig commented on OAK-4689:
Unassigning myself as there are no plans for addressing this anytime soon.
> Add information about amount of data vs. waste to oak-run
> -
>
> Key: OAK-4689
> URL: https://issues.apache.org/jira/browse/OAK-4689
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Michael Dürig
>Priority: Major
> Labels: production, tooling
>
> This is a follow up for OAK-3695, where we decided that it would be to
> expensive doing this as live monitoring.
> Instead we should add functionality to {{oak-run}} that could connect in read
> only mode to a running repository and collect information about how much data
> and how must wast the repository contains.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-4689) Add information about amount of data vs. waste to oak-run
[
https://issues.apache.org/jira/browse/OAK-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-4689:
--
Assignee: (was: Michael Dürig)
> Add information about amount of data vs. waste to oak-run
> -
>
> Key: OAK-4689
> URL: https://issues.apache.org/jira/browse/OAK-4689
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run, segment-tar
>Reporter: Michael Dürig
>Priority: Major
> Labels: production, tooling
>
> This is a follow up for OAK-3695, where we decided that it would be to
> expensive doing this as live monitoring.
> Instead we should add functionality to {{oak-run}} that could connect in read
> only mode to a running repository and collect information about how much data
> and how must wast the repository contains.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7234) Check for outdated journal at startup
[
https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813507#comment-16813507
]
Michael Dürig commented on OAK-7234:
Unassigning myself as there is no plans to take this up any time soon.
> Check for outdated journal at startup
> -
>
> Key: OAK-7234
> URL: https://issues.apache.org/jira/browse/OAK-7234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
> Labels: resilience, tooling
>
> To prevent accidentally branching the repository when the {{journal.log}}
> became outdated (e.g. OAK-3702) we could add an additional safety feature
> which would prevent the repository from starting in such cases. There's a
> couple of concerns to address:
> * What kind of tooling / guidance do we need to provide to recover should
> such a situation be detected?
> * How do we detect the {{journal.log}} being outdated?
> * How do we prevent false positives?
> * How do we deal with situation where the {{journal.log}} modifications are
> intended (e.g. by tools, of manual interventions)?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-7234) Check for outdated journal at startup
[
https://issues.apache.org/jira/browse/OAK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-7234:
--
Assignee: (was: Michael Dürig)
> Check for outdated journal at startup
> -
>
> Key: OAK-7234
> URL: https://issues.apache.org/jira/browse/OAK-7234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
> Labels: resilience, tooling
>
> To prevent accidentally branching the repository when the {{journal.log}}
> became outdated (e.g. OAK-3702) we could add an additional safety feature
> which would prevent the repository from starting in such cases. There's a
> couple of concerns to address:
> * What kind of tooling / guidance do we need to provide to recover should
> such a situation be detected?
> * How do we detect the {{journal.log}} being outdated?
> * How do we prevent false positives?
> * How do we deal with situation where the {{journal.log}} modifications are
> intended (e.g. by tools, of manual interventions)?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813505#comment-16813505 ] Michael Dürig commented on OAK-6947: [~frm], could you help with this one? > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Assignee: Francesco Mari >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-6947) Add package export versions for oak-store-spi
[ https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-6947: -- Assignee: Francesco Mari (was: Michael Dürig) > Add package export versions for oak-store-spi > - > > Key: OAK-6947 > URL: https://issues.apache.org/jira/browse/OAK-6947 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: store-spi >Reporter: angela >Assignee: Francesco Mari >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-6947.patch > > > [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong > preferences wrt to the packages we placed in the _oak-store-spi_ module? > Currently we explicitly export all packages and I think it would make sense > to enable the baseline plugin for these packages. > Any objection from your side? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8203) Build Jackrabbit Oak #2070 failed
[ https://issues.apache.org/jira/browse/OAK-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813473#comment-16813473 ] Hudson commented on OAK-8203: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2073|https://builds.apache.org/job/Jackrabbit%20Oak/2073/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2073/console] > Build Jackrabbit Oak #2070 failed > - > > Key: OAK-8203 > URL: https://issues.apache.org/jira/browse/OAK-8203 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2070 has failed. > First failed run: [Jackrabbit Oak > #2070|https://builds.apache.org/job/Jackrabbit%20Oak/2070/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2070/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8209) Improve Node.isNodeType(String) performance
Marcel Reutegger created OAK-8209:
-
Summary: Improve Node.isNodeType(String) performance
Key: OAK-8209
URL: https://issues.apache.org/jira/browse/OAK-8209
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Profiling an application running on Oak showed calls to
{{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
to reduce those calls there's probably also some potential in optimizing the
implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.
[ https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813403#comment-16813403 ] Francesco Mari commented on OAK-8186: - Surely the lower you implement the copy operation, the better the performance will be. The point is not which kind of copy operation is going to be the fastest, but how tight the coupling between your code and Oak's internals are going to be. If you build your system on top of the JCR API, you are going to be safe no matter what implementation of the JCR API you use. If you use a custom API to access the internals of Oak, you are bound to a specific configuration of Oak, and of Oak only. Moreover, this this is going to create a backwards bind. Assuming that we implement this feature in Oak, we will not be able to drop support for this feature if we decide to change the internals of our implementation. What if, at some point, we decide to save binaries on disk in chunks instead of in one big file? We will not be able to do so without breaking the contract for fast copies. Oak lives below JCR, your system lives upon it. I'm not comfortable breaking this boundary. I wasn't when the direct binary access was introduced, and I'm definitely not comfortable now. > Create API in OAK for file access to binaries in the repository. > > > Key: OAK-8186 > URL: https://issues.apache.org/jira/browse/OAK-8186 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Henry Saginor >Priority: Major > Attachments: FileCopyTest3.java, OAK File Access.jpg, > fileCopyTest-0.0.1-SNAPSHOT.jar > > > To get file access applications normally write binaries to temp files. It > would be nice if an API existed to get file access directly from OAK. This > might also meet some use cases documented at > [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase] > Suggested API and implementation can be found here [1]. Also, see attached > diagram [2]. > I can create a patch if I can get some feedback. Note that suggested API > makes it explicit that a temp file is created. I am not sure if direct access > to files in datasore would be safe. But I am open to suggestions. > [1] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java] > [2] > !OAK File Access.jpg! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8208) oak-run/rdb: add --rdbtableprefix option
[ https://issues.apache.org/jira/browse/OAK-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8208: Attachment: OAK-8208.diff > oak-run/rdb: add --rdbtableprefix option > > > Key: OAK-8208 > URL: https://issues.apache.org/jira/browse/OAK-8208 > Project: Jackrabbit Oak > Issue Type: Task > Components: rdbmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.14.0 > > Attachments: OAK-8208.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8208) oak-run/rdb: add --rdbtableprefix option
Julian Reschke created OAK-8208: --- Summary: oak-run/rdb: add --rdbtableprefix option Key: OAK-8208 URL: https://issues.apache.org/jira/browse/OAK-8208 Project: Jackrabbit Oak Issue Type: Task Components: rdbmk, run Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.14.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8207) Read-only DocumentNodeStore tries to create root document
Marcel Reutegger created OAK-8207:
-
Summary: Read-only DocumentNodeStore tries to create root document
Key: OAK-8207
URL: https://issues.apache.org/jira/browse/OAK-8207
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
When connecting a read-only DocumentNodeStore to a DocumentStore with an empty
{{nodes}} collection, the DocumentNodeStore tries to create the root document.
The operation then fails with something like:
{noformat}
Exception in thread "main"
org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Method -
createOrUpdate. Params: [nodes, [key: 0:/ new
{_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false,
_commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
at
org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.asDocumentStoreException(DocumentStoreException.java:179)
at
org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:131)
at
org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:114)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:425)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:280)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:264)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:624)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBuilder.build(DocumentNodeStoreBuilder.java:174)
at
org.apache.jackrabbit.oak.run.ClusterNodesCommand.execute(ClusterNodesCommand.java:65)
at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
Caused by: java.lang.UnsupportedOperationException: Method - createOrUpdate.
Params: [nodes, [key: 0:/ new {_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false,
_commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
at
org.apache.jackrabbit.oak.plugins.document.util.ReadOnlyDocumentStoreWrapperFactory$1.invoke(ReadOnlyDocumentStoreWrapperFactory.java:38)
at com.sun.proxy.$Proxy0.createOrUpdate(Unknown Source)
at
org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:365)
... 6 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.
[ https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813336#comment-16813336 ] Ruben Reusser commented on OAK-8186: [~mduerig] nio.Files.copy is a file system copy (operates on files directly), o.a.c.io.IOUtils.copy is a stream copy and represents the way jackrabbit file vault and other upstream applications using oak mostly create temp files. > Create API in OAK for file access to binaries in the repository. > > > Key: OAK-8186 > URL: https://issues.apache.org/jira/browse/OAK-8186 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Henry Saginor >Priority: Major > Attachments: FileCopyTest3.java, OAK File Access.jpg, > fileCopyTest-0.0.1-SNAPSHOT.jar > > > To get file access applications normally write binaries to temp files. It > would be nice if an API existed to get file access directly from OAK. This > might also meet some use cases documented at > [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase] > Suggested API and implementation can be found here [1]. Also, see attached > diagram [2]. > I can create a patch if I can get some feedback. Note that suggested API > makes it explicit that a temp file is created. I am not sure if direct access > to files in datasore would be safe. But I am open to suggestions. > [1] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java] > [2] > !OAK File Access.jpg! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8203) Build Jackrabbit Oak #2070 failed
[ https://issues.apache.org/jira/browse/OAK-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813334#comment-16813334 ] Hudson commented on OAK-8203: - Build is still failing. Failed run: [Jackrabbit Oak #2072|https://builds.apache.org/job/Jackrabbit%20Oak/2072/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2072/console] > Build Jackrabbit Oak #2070 failed > - > > Key: OAK-8203 > URL: https://issues.apache.org/jira/browse/OAK-8203 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2070 has failed. > First failed run: [Jackrabbit Oak > #2070|https://builds.apache.org/job/Jackrabbit%20Oak/2070/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2070/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8206) Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable Oak release
[ https://issues.apache.org/jira/browse/OAK-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8206. - Resolution: Fixed trunk: [r1857178|http://svn.apache.org/r1857178] > Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable > Oak release > --- > > Key: OAK-8206 > URL: https://issues.apache.org/jira/browse/OAK-8206 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8206) Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable Oak release
[ https://issues.apache.org/jira/browse/OAK-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8206: Summary: Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable Oak release (was: Revert Jackrabbit dependency to last stable for stable Oak release) > Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable > Oak release > --- > > Key: OAK-8206 > URL: https://issues.apache.org/jira/browse/OAK-8206 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Blocker > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8206) Revert Jackrabbit dependency to last stable for stable Oak release
Julian Reschke created OAK-8206: --- Summary: Revert Jackrabbit dependency to last stable for stable Oak release Key: OAK-8206 URL: https://issues.apache.org/jira/browse/OAK-8206 Project: Jackrabbit Oak Issue Type: Task Components: parent Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.12.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813283#comment-16813283 ] Julian Reschke edited comment on OAK-8146 at 4/9/19 11:27 AM: -- [^OAK-8146-2.patch] - generic table formatter - use "!" instead of "-" when recovery needed but not running - add "Left" (until lease timeout) New option --verbose adds: "LastRootRev" and "OakVersion". TODO: documentation was (Author: reschke): [^OAK-8146-2.patch] - generic table formatter - use "!" instead of "-" when recovery needed but not running - add "Left" (until lease timeout) New option --verbose adds: "LastRootRev" and "OakVersion". > oak-run support for inspecting/modifying clusterNodeInfo > > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146.diff, > OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813283#comment-16813283 ] Julian Reschke commented on OAK-8146: - [^OAK-8146-2.patch] - generic table formatter - use "!" instead of "-" when recovery needed but not running - add "Left" (until lease timeout) New option --verbose adds: "LastRootRev" and "OakVersion". > oak-run support for inspecting/modifying clusterNodeInfo > > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146.diff, > OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8146: Attachment: OAK-8146-2.diff > oak-run support for inspecting/modifying clusterNodeInfo > > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146.diff, > OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5506:
--
Fix Version/s: (was: 1.12.0)
> reject item 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
>Priority: Minor
> Labels: resilience
> Fix For: 1.14.0
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff,
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.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-8205) Add benchmark for Node.isNodeType()
[
https://issues.apache.org/jira/browse/OAK-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-8205:
--
Fix Version/s: 1.10.3
Merged into 1.10 branch to have a baseline: https://svn.apache.org/r1857166
> Add benchmark for Node.isNodeType()
> ---
>
> Key: OAK-8205
> URL: https://issues.apache.org/jira/browse/OAK-8205
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0, 1.10.3
>
>
> Add a benchmark for {{Node.isNodeType(String)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7635) oak-run check should support Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7635:
--
Fix Version/s: (was: 1.12.0)
> oak-run check should support Azure Segment Store
>
>
> Key: OAK-7635
> URL: https://issues.apache.org/jira/browse/OAK-7635
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tooling
> Fix For: 1.14.0
>
>
> {{oak-run check}} should accept Azure URIs for the segment store in order to
> be able to check for data integrity. This will come handy in the light of
> remote compacted segment stores and/or sidegraded remote segment stores (see
> OAK-7623, OAK-7459).
> The Azure URI will be taken as argument and will have the following format:
> {{az:[https://myaccount.blob.core.windows.net/container/repo]}}, where _az_
> identifies the cloud provider. The last missing piece is the secret key which
> will be supplied as an environment variable, i.e. _AZURE_SECRET_KEY._
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-1150) NodeType index: don't index all primary and mixin types
[ https://issues.apache.org/jira/browse/OAK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-1150: -- Fix Version/s: 1.14.0 > NodeType index: don't index all primary and mixin types > --- > > Key: OAK-1150 > URL: https://issues.apache.org/jira/browse/OAK-1150 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Currently, the nodetype index indexes all primary types and mixin types > (including nt:base I think). > This results in many nodes in this index, which unnecessarily increases the > repository size, but doesn't really help executing queries (running a query > to get all nt:base nodes doesn't benefit much from using the nodetype index). > It should also help reduce writes in updating the index, for example for > OAK-1099 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7846) Add a tool to export the tree pointed to by a node record
[ https://issues.apache.org/jira/browse/OAK-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7846: -- Fix Version/s: 1.14.0 > Add a tool to export the tree pointed to by a node record > - > > Key: OAK-7846 > URL: https://issues.apache.org/jira/browse/OAK-7846 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Affects Versions: 1.10.0 >Reporter: Francesco Mari >Assignee: Francesco Mari >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-7846-01.patch, OAK-7846-02.patch > > > oak-segment-tar should have a tool that allows exporting a tree pointed to by > a node record. The tool must be written in a way that plays along with > existing Oak tools (see OAK-7834) and conventional UNIX ones. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4814) Add orderby support for nodename index
[ https://issues.apache.org/jira/browse/OAK-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4814: -- Fix Version/s: 1.14.0 > Add orderby support for nodename index > -- > > Key: OAK-4814 > URL: https://issues.apache.org/jira/browse/OAK-4814 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Affects Versions: 1.5.10 >Reporter: Ankush Malhotra >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > In OAK-1752 you have implemented the index support for :nodeName. The JCR > Query explain tool shows that it is used for conditions like equals. > But it is not used for ORDER BY name() . > Is name() supported in order by clause? If yes then we would need to add > support for that in oak-lucene -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2787) Faster multi threaded indexing / text extraction for binary content
[ https://issues.apache.org/jira/browse/OAK-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2787: -- Fix Version/s: 1.14.0 > Faster multi threaded indexing / text extraction for binary content > --- > > Key: OAK-2787 > URL: https://issues.apache.org/jira/browse/OAK-2787 > Project: Jackrabbit Oak > Issue Type: Wish > Components: lucene >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > With Lucene based indexing the indexing process is single threaded. This > hamper the indexing of binary content as on a multi processor system only > single thread can be used to perform the indexing > [~ianeboston] Suggested a possible approach [1] involving a 2 phase indexing > # In first phase detect the nodes to be indexed and start the full text > extraction of the binary content. Post extraction save the binary token > stream back to the node as a hidden data. In this phase the node properties > can still be indexed and a marker field would be added to indicate the > fulltext index is still pending > # Later in 2nd phase look for all such Lucene docs and then update them with > the saved token stream > This would allow the text extraction logic to be decouple from Lucene > indexing logic > [1] http://markmail.org/thread/2w5o4bwqsosb6esu -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5152) Improve overflow handling in ChangeSetFilterImpl
[ https://issues.apache.org/jira/browse/OAK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5152: -- Fix Version/s: 1.14.0 > Improve overflow handling in ChangeSetFilterImpl > > > Key: OAK-5152 > URL: https://issues.apache.org/jira/browse/OAK-5152 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > As described in OAK-5151 when a ChangeSet overflows, the ChangeSetFilterImpl > treats the changes as included and doesn't go further into the remaining, > perhaps not-overflown other sets. Besides more testing it wouldn't be much > effort to change this though. Putting this as outside of 1.6 scope for now > though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5544) Improve indexing resilience
[ https://issues.apache.org/jira/browse/OAK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5544: -- Fix Version/s: (was: 1.12.0) > Improve indexing resilience > --- > > Key: OAK-5544 > URL: https://issues.apache.org/jira/browse/OAK-5544 > Project: Jackrabbit Oak > Issue Type: Epic > Components: lucene >Reporter: Alexander Saar >Assignee: Chetan Mehrotra >Priority: Critical > Labels: resilience > Fix For: 1.14.0 > > > grouping the improvements for indexer resilience in this issue for easier > tracking -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions
[
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3767:
--
Fix Version/s: (was: 1.12.0)
> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.14.0
>
>
> We need to provide an explicit support for extending out of the box shipped
> index definition by an application built on top of Oak. Consider a Sling
> based app which ships with an index on assets like /oak:index/assetIndex.
> This application is now used in a project where some project specific
> extensions are to be done i.e. some new custom asset properties are to be
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate
> index which includes the project specific properties. This has following
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and
> /oak:index/myAssetIndex would index same asset nodes they would be storing
> the same asset path twice and hence cause an increase in memory consumption
> by the index
> # Increase in indexing time - With increase in number of indexes at same
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes
> they would compete in answering queries related to assets leading to
> ambiguity in index selection by query engine.
> Given above it would be better to avoid such cases and provide an explicit
> support for extending the index definitions. This can be done by enabling
> support for adding index definition extensions under a sub directory in a sub
> directory under /oak:index
> {noformat}
> /oak:index
> + assetIndex
> + apps
> + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for
> indexing and querying.
> *question*. Shall we allow this only under root or under any arbitrary path
> as well? For example /content.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7358) Remove all usage of java.security.acl.Group for Java 13
[ https://issues.apache.org/jira/browse/OAK-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7358: -- Fix Version/s: 1.14.0 > Remove all usage of java.security.acl.Group for Java 13 > --- > > Key: OAK-7358 > URL: https://issues.apache.org/jira/browse/OAK-7358 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Followup of OAK-7024 for the actual removal of the Group class from the > codebase to be java 11 compliant. > Not sure what to use for 'fix version', I went with 1.9.0 so this remains on > the radar, but we can push it out as needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6769) Convert oak-search-mt to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6769: -- Fix Version/s: 1.14.0 > Convert oak-search-mt to OSGi R6 annotations > > > Key: OAK-6769 > URL: https://issues.apache.org/jira/browse/OAK-6769 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6767) Remove felix SCR annotation support from parent pom
[ https://issues.apache.org/jira/browse/OAK-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6767: -- Fix Version/s: (was: 1.12.0) > Remove felix SCR annotation support from parent pom > --- > > Key: OAK-6767 > URL: https://issues.apache.org/jira/browse/OAK-6767 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: parent >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3219) Lucene IndexPlanner should also account for number of property constraints evaluated while giving cost estimation
[
https://issues.apache.org/jira/browse/OAK-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3219:
--
Fix Version/s: 1.14.0
> Lucene IndexPlanner should also account for number of property constraints
> evaluated while giving cost estimation
> -
>
> Key: OAK-3219
> URL: https://issues.apache.org/jira/browse/OAK-3219
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Labels: performance
> Fix For: 1.12.0, 1.14.0
>
>
> Currently the cost returned by Lucene index is a function of number of
> indexed documents present in the index. If the number of indexed entries are
> high then it might reduce chances of this index getting selected if some
> property index also support of the property constraint.
> {noformat}
> /jcr:root/content/freestyle-cms/customers//element(*, cq:Page)
> [(jcr:content/@title = 'm' or jcr:like(jcr:content/@title, 'm%'))
> and jcr:content/@sling:resourceType = '/components/page/customer’]
> {noformat}
> Consider above query with following index definition
> * A property index on resourceType
> * A Lucene index for cq:Page with properties {{jcr:content/title}},
> {{jcr:content/sling:resourceType}} indexed and also path restriction
> evaluation enabled
> Now what the two indexes can help in
> # Property index
> ## Path restriction
> ## Property restriction on {{sling:resourceType}}
> # Lucene index
> ## NodeType restriction
> ## Property restriction on {{sling:resourceType}}
> ## Property restriction on {{title}}
> ## Path restriction
> Now cost estimate currently works like this
> * Property index - {{f(indexedValueEstimate, estimateOfNodesUnderGivenPath)}}
> ** indexedValueEstimate - For 'sling:resourceType=foo' its the approximate
> count for nodes having that as 'foo'
> ** estimateOfNodesUnderGivenPath - Its derived from an approximate estimation
> of nodes present under given path
> * Lucene Index - {{f(totalIndexedEntries)}}
> As cost of Lucene is too simple it does not reflect the reality. Following 2
> changes can be done to make it better
> * Given that Lucene index can handle multiple constraints compared (4) to
> property index (2), the cost estimate returned by it should also reflect this
> state. This can be done by setting costPerEntry to 1/(no of property
> restriction evaluated)
> * Get the count for queried property value - This is similar to what
> PropertyIndex does and assumes that Lucene can provide that information in
> O(1) cost. In case of multiple supported property restriction this can be
> minima of all
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4647) Multiplexing support in PropertyIndexStats MBean
[
https://issues.apache.org/jira/browse/OAK-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4647:
--
Fix Version/s: 1.14.0
> Multiplexing support in PropertyIndexStats MBean
>
>
> Key: OAK-4647
> URL: https://issues.apache.org/jira/browse/OAK-4647
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.12.0, 1.14.0
>
>
> {{PropertyIndexStats}} MBean added in OAK-4144 allows introspecting property
> index content. This needs to be adapted to support updated storage format
> when multiplexing is enabled
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4614) Collection of observation resilience issues
[ https://issues.apache.org/jira/browse/OAK-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4614: -- Fix Version/s: (was: 1.12.0) > Collection of observation resilience issues > --- > > Key: OAK-4614 > URL: https://issues.apache.org/jira/browse/OAK-4614 > Project: Jackrabbit Oak > Issue Type: Epic > Components: core, documentmk, jcr >Reporter: Marcel Reutegger >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7941) Test failure: IndexCopierTest.directoryContentMismatch_COR
[
https://issues.apache.org/jira/browse/OAK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7941:
--
Fix Version/s: (was: 1.12.0)
> Test failure: IndexCopierTest.directoryContentMismatch_COR
> --
>
> Key: OAK-7941
> URL: https://issues.apache.org/jira/browse/OAK-7941
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Priority: Major
> Fix For: 1.14.0
>
>
> No description is provided
> The build Jackrabbit Oak #1830 has failed.
> First failed run: [Jackrabbit Oak
> #1830|https://builds.apache.org/job/Jackrabbit%20Oak/1830/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1830/console]
> {noformat}
> [ERROR] Tests run: 24, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.832 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest
> [ERROR]
> directoryContentMismatch_COR(org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest)
> Time elapsed: 0.08 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.readAndAssert(IndexCopierTest.java:1119)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.directoryContentMismatch_COR(IndexCopierTest.java:1081)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6760) Convert oak-blob-cloud to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6760: -- Fix Version/s: (was: 1.12.0) > Convert oak-blob-cloud to OSGi R6 annotations > - > > Key: OAK-6760 > URL: https://issues.apache.org/jira/browse/OAK-6760 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: blob-cloud >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6501) Support adding or updating index definitions via oak-run: JSON data format
[
https://issues.apache.org/jira/browse/OAK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6501:
--
Fix Version/s: (was: 1.12.0)
> Support adding or updating index definitions via oak-run: JSON data format
> --
>
> Key: OAK-6501
> URL: https://issues.apache.org/jira/browse/OAK-6501
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-6471 we have support for index definitions via JSON.
> I'm not happy with the escaping (OAK-6476) ("If the string starts with
> namespace..."), I think it's a bit dangerous. Need to investigate whether
> this prevents importing index definitions exported via JSON
> (localhost:/oak:index/lucene.tidy.-1.json).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4581) Persistent local journal for more reliable event generation
[
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4581:
--
Fix Version/s: (was: 1.12.0)
> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Chetan Mehrotra
>Priority: Major
> Labels: observation
> Fix For: 1.14.0
>
> Attachments: OAK-4581.v0.patch
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple
> drawbacks. Quite a bit of work is done to make diff generation faster.
> However there are still chances of event queue getting filled up.
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous
> observer
> # Observors which are meant to handle such events in async way (by virtue of
> being wrapped in BackgroundObserver) would instead pull the events from this
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form.
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of
> SegmentNodeStore root state looks like{color} - Possible the RecordId of
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote
> journal to determine the affected paths. Which reduces the need for
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains
> information about affected path. Similar to what is current being stored in
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching.
> [~mreutegg] suggested that for persisted local journal we can also utilize a
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis.
> This would allow each Listener to "pull" content changes and generate diff as
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2]
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3]
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-3373) Observers dont survive store restart (was: LuceneIndexProvider: java.lang.IllegalStateException: open)
[
https://issues.apache.org/jira/browse/OAK-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3373:
--
Fix Version/s: (was: 1.12.0)
> Observers dont survive store restart (was: LuceneIndexProvider:
> java.lang.IllegalStateException: open)
> --
>
> Key: OAK-3373
> URL: https://issues.apache.org/jira/browse/OAK-3373
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.5
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.14.0
>
>
> The following exception occurs when stopping, then immediately re-starting
> the oak-core bundle (which was done as part of testing for OAK-3250 - but can
> be reproduced independently). It's not clear what the consequences are
> though..
> {code}08.09.2015 14:20:26.960 *ERROR* [oak-lucene-0]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught
> exception in
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@3a4a6c5c
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Error
> occurred while fetching children for path /oak:index/authorizables
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:902)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1082)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$100(DocumentNodeState.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.fetchMore(DocumentNodeState.java:716)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.(DocumentNodeState.java:681)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$1.iterator(DocumentNodeState.java:289)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:129)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:108)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:73)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:127)
> at
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:121)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: open
> at org.bson.util.Assertions.isTrue(Assertions.java:36)
> at
> com.mongodb.DBTCPConnector.isMongosConnection(DBTCPConnector.java:367)
> at com.mongodb.Mongo.isMongosConnection(Mongo.java:622)
> at com.mongodb.DBCursor._check(DBCursor.java:494)
> at com.mongodb.DBCursor._hasNext(DBCursor.java:621)
> at
[jira] [Updated] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider
[
https://issues.apache.org/jira/browse/OAK-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-8187:
--
Fix Version/s: 1.14.0
> Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider
> and RestrictionProvider
> -
>
> Key: OAK-8187
> URL: https://issues.apache.org/jira/browse/OAK-8187
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> The way multiple {{AuthorizableNodeName}}, {{AuthorizableActionProvider}} and
> {{RestrictionProvider}} service are handled by
> {{SecurityProviderRegistration}} suffers from the same issues as was reported
> for {{UserAuthenticationFactory}} (see OAK-8045). Once OAK-8045 is addressed
> we should adopt the same behavior for the remaining bind/unbind methods for
> the interfaces mentioned above.
> cc: [~stillalex]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5858) Lucene index may return the wrong result if path is excluded
[
https://issues.apache.org/jira/browse/OAK-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5858:
--
Fix Version/s: (was: 1.12.0)
> Lucene index may return the wrong result if path is excluded
>
>
> Key: OAK-5858
> URL: https://issues.apache.org/jira/browse/OAK-5858
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> If a query uses a Lucene index that has "excludedPaths", the query result may
> be wrong (not contain all matching nodes). This is case even if there is a
> property index available for the queried property. Example:
> {noformat}
> Indexes:
> /oak:index/resourceType/type = "property"
> /oak:index/lucene/type = "lucene"
> /oak:index/lucene/excludedPaths = ["/etc"]
> /oak:index/lucene/indexRules/nt:base/properties/resourceType
> Query:
> /jcr:root/etc//*[jcr:like(@resourceType, "x%y")]
> Index cost:
> cost for /oak:index/resourceType is 1602.0
> cost for /oak:index/lucene is 1001.0
> Result:
> (empty)
> Expected result:
> /etc/a
> /etc/b
> {noformat}
> Here, the lucene index is picked, even thought the query explicitly queries
> for /etc, and the lucene index has this path excluded.
> I think the lucene index should not be picked in case the index does not
> match the query path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7754) Option to disable BlobTracker
[ https://issues.apache.org/jira/browse/OAK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7754: -- Fix Version/s: 1.14.0 > Option to disable BlobTracker > - > > Key: OAK-7754 > URL: https://issues.apache.org/jira/browse/OAK-7754 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-plugins >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > Enable an option to disable blob tracker completely for deployments where > DSGC is explicitly disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6844) Consistency checker Directory value is always ":data"
[
https://issues.apache.org/jira/browse/OAK-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6844:
--
Fix Version/s: 1.14.0
> Consistency checker Directory value is always ":data"
> -
>
> Key: OAK-6844
> URL: https://issues.apache.org/jira/browse/OAK-6844
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Affects Versions: 1.7.9
>Reporter: Paul Chibulcuteanu
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.12.0, 1.14.0
>
>
> When running a _fullCheck_ consistency check from the Lucene Index statistics
> MBean, the _Directory_ results is always _:data_
> See below:
> {code}
> /oak:index/lucene => VALID
> Size : 42.3 MB
> Directory : :data
> Size : 42.3 MB
> Num docs : 159132
> CheckIndex status : true
> Time taken : 3.544 s
> {code}
> I'm not really sure what information should be put here, but the _:data_
> value is confusing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7263) oak-lucene should not depend on oak-store-document
[
https://issues.apache.org/jira/browse/OAK-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7263:
--
Fix Version/s: 1.14.0
> oak-lucene should not depend on oak-store-document
> --
>
> Key: OAK-7263
> URL: https://issues.apache.org/jira/browse/OAK-7263
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> {{oak-lucene}} has a hard dependency on {{oak-store-document}} and that looks
> wrong to me.
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project oak-lucene: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyBuilder
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR] location: class
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
> cannot find symbol
> [ERROR] symbol: class JournalProperty
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
> package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyService
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
> cannot find symbol
> [ERROR] symbol: class JournalPropertyBuilder
> [ERROR] location: class
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
> method does not override or implement a method from a supertype
> [ERROR]
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
> method does not override or implement a method from a supertype
> [ERROR]
>
[jira] [Updated] (OAK-8141) Replace String path with custom data type
[ https://issues.apache.org/jira/browse/OAK-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-8141: -- Fix Version/s: (was: 1.12.0) > Replace String path with custom data type > - > > Key: OAK-8141 > URL: https://issues.apache.org/jira/browse/OAK-8141 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-8141.patch > > > DocumentNodeState objects and other related data is currently identified with > a String path in the various caches in the DocumentNodeStore. Read benchmarks > like GetDeepNodeTest that only read data from memory are significantly slower > on a DocumentNodeStore compared to a SegmentNodeStore. In these kind of tests > the DocumentNodeStore is usually busy with String operations like > constructing the path for a child node or calculating the hash code for a > lookup in a cache. > This issue is about a potential improvement that replaces the use of a plain > String for the path of a DocumentNodeState and use a custom Path type instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7261) DocumentStore: inconsistent behaviour for invalid Strings as document ID
[ https://issues.apache.org/jira/browse/OAK-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7261: -- Fix Version/s: (was: 1.12.0) > DocumentStore: inconsistent behaviour for invalid Strings as document ID > > > Key: OAK-7261 > URL: https://issues.apache.org/jira/browse/OAK-7261 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.14.0 > > > - H2DB and Derby roundtrip any string > - PostgreSQL rejects the invalid string early > - DB2 and Oracle fail the same way as segment store (they persist the > replacement character) (see OAK-5506) > - MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the > RDBDocumentStore's fault, because the ID column is binary, and we transform > to byte sequences ourselves > - Mongo claims it saved the document, but upon lookup, returns something > with a different ID > Note that due to how RDB reads work, the returned document has the ID that > was requested, not what the DB actually contains. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7489) Update derby dependency to 10.14.2.0
[ https://issues.apache.org/jira/browse/OAK-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7489: -- Fix Version/s: (was: 1.12.0) > Update derby dependency to 10.14.2.0 > > > Key: OAK-7489 > URL: https://issues.apache.org/jira/browse/OAK-7489 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7902) Update osgi-mock to 2.4.2
[ https://issues.apache.org/jira/browse/OAK-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7902: -- Fix Version/s: (was: 1.12.0) > Update osgi-mock to 2.4.2 > - > > Key: OAK-7902 > URL: https://issues.apache.org/jira/browse/OAK-7902 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Affects Versions: 1.9.11 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.14.0 > > > The current version (2.3.6) has an indirect dependency on the findbugs > annotations that we already got rid of. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8150) RDB*Store: add Oracle specific documentation
[ https://issues.apache.org/jira/browse/OAK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-8150: -- Fix Version/s: (was: 1.12.0) > RDB*Store: add Oracle specific documentation > > > Key: OAK-8150 > URL: https://issues.apache.org/jira/browse/OAK-8150 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7489) Update derby dependency to 10.14.2.0
[ https://issues.apache.org/jira/browse/OAK-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7489: -- Fix Version/s: 1.14.0 > Update derby dependency to 10.14.2.0 > > > Key: OAK-7489 > URL: https://issues.apache.org/jira/browse/OAK-7489 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7902) Update osgi-mock to 2.4.2
[ https://issues.apache.org/jira/browse/OAK-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7902: -- Fix Version/s: 1.14.0 > Update osgi-mock to 2.4.2 > - > > Key: OAK-7902 > URL: https://issues.apache.org/jira/browse/OAK-7902 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Affects Versions: 1.9.11 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > > The current version (2.3.6) has an indirect dependency on the findbugs > annotations that we already got rid of. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8150) RDB*Store: add Oracle specific documentation
[ https://issues.apache.org/jira/browse/OAK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-8150: -- Fix Version/s: 1.14.0 > RDB*Store: add Oracle specific documentation > > > Key: OAK-8150 > URL: https://issues.apache.org/jira/browse/OAK-8150 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: doc, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12.0, 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7261) DocumentStore: inconsistent behaviour for invalid Strings as document ID
[ https://issues.apache.org/jira/browse/OAK-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7261: -- Fix Version/s: 1.14.0 > DocumentStore: inconsistent behaviour for invalid Strings as document ID > > > Key: OAK-7261 > URL: https://issues.apache.org/jira/browse/OAK-7261 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk, rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.12.0, 1.14.0 > > > - H2DB and Derby roundtrip any string > - PostgreSQL rejects the invalid string early > - DB2 and Oracle fail the same way as segment store (they persist the > replacement character) (see OAK-5506) > - MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the > RDBDocumentStore's fault, because the ID column is binary, and we transform > to byte sequences ourselves > - Mongo claims it saved the document, but upon lookup, returns something > with a different ID > Note that due to how RDB reads work, the returned document has the ID that > was requested, not what the DB actually contains. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8141) Replace String path with custom data type
[ https://issues.apache.org/jira/browse/OAK-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-8141: -- Fix Version/s: 1.14.0 > Replace String path with custom data type > - > > Key: OAK-8141 > URL: https://issues.apache.org/jira/browse/OAK-8141 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.12.0, 1.14.0 > > Attachments: OAK-8141.patch > > > DocumentNodeState objects and other related data is currently identified with > a String path in the various caches in the DocumentNodeStore. Read benchmarks > like GetDeepNodeTest that only read data from memory are significantly slower > on a DocumentNodeStore compared to a SegmentNodeStore. In these kind of tests > the DocumentNodeStore is usually busy with String operations like > constructing the path for a child node or calculating the hash code for a > lookup in a cache. > This issue is about a potential improvement that replaces the use of a plain > String for the path of a DocumentNodeState and use a custom Path type instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7065) Remove orphan file from local directory in case indexing fails
[ https://issues.apache.org/jira/browse/OAK-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7065: -- Fix Version/s: (was: 1.12.0) > Remove orphan file from local directory in case indexing fails > -- > > Key: OAK-7065 > URL: https://issues.apache.org/jira/browse/OAK-7065 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.14.0 > > > If an indexing cycle fails for some reason it may leave orphan files in local > directory. Later on in next indexing cycle Lucene would try to create files > with same name on local disk and this may fail on Windows where such files > may have been memory mapped and hence cannot be deleted. > We should analyze such a scenario and see if system can handle the failure > case properly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2777) Minimize the cost calculation for queries using reference restrictions.
[ https://issues.apache.org/jira/browse/OAK-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2777: -- Fix Version/s: (was: 1.12.0) > Minimize the cost calculation for queries using reference restrictions. > --- > > Key: OAK-2777 > URL: https://issues.apache.org/jira/browse/OAK-2777 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, query >Affects Versions: 1.1.2, 1.2 >Reporter: Przemo Pakulski >Assignee: Thomas Mueller >Priority: Major > Labels: performance > Fix For: 1.14.0 > > Attachments: oak-2777.patch > > > According to the javadocs (QueryIndex) minimum cost for index is 1. Currently > ReferenceIndex returns this minimum value, when it can be used for the query. > But even then cost for remaining indexes is still calculated. We could skip > cost calculation of remaining indexes if we achieved the minimum cost already. > It will speed up all queries which can leverage the reference Index. > Example query: > SELECT * FROM [nt:base] WHERE PROPERTY([rep:members], 'WeakReference') = > '345bef9b-ffa1-3e09-85df-1e03cfa0fb37' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5776) Build failure: Cannot create directory : Filename too long
[ https://issues.apache.org/jira/browse/OAK-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5776: -- Fix Version/s: (was: 1.12.0) > Build failure: Cannot create directory : Filename too long > -- > > Key: OAK-5776 > URL: https://issues.apache.org/jira/browse/OAK-5776 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > Labels: CI, build-failure, test-failure, windows > Fix For: 1.14.0 > > > Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/ > The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) > 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #473 > has failed. > First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited > security) 64-bit Windows > only,nsfixtures=DOCUMENT_NS,profile=integrationTesting > #473|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/] > [console > log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7634) Repository migration docs should include info on TAR <-> Azure sidegrade
[ https://issues.apache.org/jira/browse/OAK-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7634: -- Fix Version/s: (was: 1.12.0) > Repository migration docs should include info on TAR <-> Azure sidegrade > > > Key: OAK-7634 > URL: https://issues.apache.org/jira/browse/OAK-7634 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5932) Use static optional greedy policy for BlobStore in DocumentNodeStoreService
[
https://issues.apache.org/jira/browse/OAK-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5932:
--
Fix Version/s: (was: 1.12.0)
> Use static optional greedy policy for BlobStore in DocumentNodeStoreService
> ---
>
> Key: OAK-5932
> URL: https://issues.apache.org/jira/browse/OAK-5932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently {{DocumentNodeStoreService}} uses DYNAMIC policy for BlobStore and
> DataSource. This leads to complexity in activation due to dynamic nature of
> OSGi.
> To simplify that we should switch to static, greedy policy. This approach is
> used by SegmentNodeStoreService as part of OAK-5223 and reduces the setup
> complexity quite a bit
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-6513) Journal based Async Indexer
[
https://issues.apache.org/jira/browse/OAK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6513:
--
Fix Version/s: (was: 1.12.0)
> Journal based Async Indexer
> ---
>
> Key: OAK-6513
> URL: https://issues.apache.org/jira/browse/OAK-6513
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Current async indexer design is based on NodeState diff. This has served us
> fine so far however off late it is not able to perform well if rate of
> repository writes is high. When changes happen faster than index-update can
> process them, larger and larger diffs will happen. These make index-updates
> slower, which again lead to the next diff being ever larger than the one
> before (assuming a constant ingestion rate).
> In current diff based flow the indexer performs complete diff for all changes
> happening between 2 cycle. It may happen that lots of writes happens but not
> much indexable content is written. So doing diff there is a wasted effort.
> In 1.6 release for NRT Indexing we implemented a journal based indexing for
> external changes(OAK-4808, OAK-5430). That approach can be generalized and
> used for async indexing.
> Before talking about the journal based approach lets see how IndexEditor work
> currently
> h4. IndexEditor
> Currently any IndexEditor performs 2 tasks
> # Identify which node is to be indexed based on some index definition. The
> Editor gets invoked as part of content diff where it determines which
> NodeState is to be indexed
> # Update the index based on node to be indexed
> For e.g. in oak-lucene we have LuceneIndexEditor which identifies the
> NodeStates to be indexed and LuceneDocumentMaker which constructs the Lucene
> Document from NodeState to be indexed. For journal based approach we can
> decouple these 2 parts and thus have
> * IndexEditor - Identifies which all paths need to be indexed for given index
> definition
> * IndexUpdater - Updates the index based on given NodeState and its path
> h4. High Level Flow
> # Session Commit Flow
> ## Each index type would provide a IndexEditor which would be invoked as part
> of commit (like sync indexes). These IndexEditor would just determine which
> paths needs to be indexed.
> ## As part of commit the paths to be indexed would be written to journal.
> # AsyncIndexUpdate flow
> ## AsyncIndexUpdate would query this journal to fetch all such indexed paths
> between the 2 checkpoints
> ## Based on the index path data it would invoke the {{IndexUpdater}} to
> update the index for that path
> ## Merge the index updates
> h4. Benefits
> Such a design would have following impact
> # More work done as part of write
> # Marking of indexable content is distributed hence at indexing time lesser
> work to be done
> # Indexing can progress in batches
> # The indexers can be called in parallel
> h4. Journal Implementation
> DocumentNodeStore currently has an in built journal which is being used for
> NRT Indexing. That feature can be exposed as an api.
> For scaling index this design is mostly required for cluster case. So we can
> possibly have both indexing support implemented and use the journal based
> support for DocumentNodeStore setups. Or we can look into implementing such a
> journal for SegmentNodeStore setups also
> h4. Open Points
> * Journal support in SegmentNodeStore
> * Handling deletes.
> Detailed proposal -
> https://wiki.apache.org/jackrabbit/Journal%20based%20Async%20Indexer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-2787) Faster multi threaded indexing / text extraction for binary content
[ https://issues.apache.org/jira/browse/OAK-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2787: -- Fix Version/s: (was: 1.12.0) > Faster multi threaded indexing / text extraction for binary content > --- > > Key: OAK-2787 > URL: https://issues.apache.org/jira/browse/OAK-2787 > Project: Jackrabbit Oak > Issue Type: Wish > Components: lucene >Reporter: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > > With Lucene based indexing the indexing process is single threaded. This > hamper the indexing of binary content as on a multi processor system only > single thread can be used to perform the indexing > [~ianeboston] Suggested a possible approach [1] involving a 2 phase indexing > # In first phase detect the nodes to be indexed and start the full text > extraction of the binary content. Post extraction save the binary token > stream back to the node as a hidden data. In this phase the node properties > can still be indexed and a marker field would be added to indicate the > fulltext index is still pending > # Later in 2nd phase look for all such Lucene docs and then update them with > the saved token stream > This would allow the text extraction logic to be decouple from Lucene > indexing logic > [1] http://markmail.org/thread/2w5o4bwqsosb6esu -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6098) Build timeout
[
https://issues.apache.org/jira/browse/OAK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6098:
--
Fix Version/s: (was: 1.12.0)
> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
> Labels: CI, jenkins, test-failure
> Fix For: 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually
> the build takes around 40mins.
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
> Also timed out on https://builds.apache.org/computer/ubuntu-eu2. See
> https://builds.apache.org/job/Jackrabbit%20Oak/246/
> Also timed out on https://builds.apache.org/computer/ubuntu-2. See
> https://builds.apache.org/job/Jackrabbit%20Oak/267/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5369) Lucene Property Index: Syntax Error, cannot parse
[
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5369:
--
Fix Version/s: (was: 1.12.0)
> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846]
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot
> parse hello -- world:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
> at
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
> at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
> at
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
> at
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
> at
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
> at
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by:
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax
> Error, cannot parse hello -- world:
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
> at
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxParser.java:204)
> at
>
[jira] [Updated] (OAK-6769) Convert oak-search-mt to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-6769: -- Fix Version/s: (was: 1.12.0) > Convert oak-search-mt to OSGi R6 annotations > > > Key: OAK-6769 > URL: https://issues.apache.org/jira/browse/OAK-6769 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Robert Munteanu >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7660) Refactor AzureCompact and Compact
[
https://issues.apache.org/jira/browse/OAK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7660:
--
Fix Version/s: (was: 1.12.0)
> Refactor AzureCompact and Compact
> -
>
> Key: OAK-7660
> URL: https://issues.apache.org/jira/browse/OAK-7660
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tech-debt, technical_debt, tooling
> Fix For: 1.14.0
>
>
> {{AzureCompact}} in {{oak-segment-azure}} follows closely the structure and
> logic of {{Compact}} in {{oak-segment-tar}}. Since the only thing which
> differs is the underlying persistence used (remote in Azure vs. local in TAR
> files), the common logic should be extracted in a super-class, extended by
> both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7043) Collect SegmentStore stats as part of status zip
[ https://issues.apache.org/jira/browse/OAK-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7043: -- Fix Version/s: (was: 1.12.0) > Collect SegmentStore stats as part of status zip > > > Key: OAK-7043 > URL: https://issues.apache.org/jira/browse/OAK-7043 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Chetan Mehrotra >Priority: Major > Labels: monitoring, production > Fix For: 1.14.0 > > > Many times while investigating issue we request customer to provide to size > of segmentstore and at times list of segmentstore directory. It would be > useful if there is an InventoryPrinter for SegmentStore which can include > * Size of segment store > * Listing of segment store directory > * Possibly tail of journal.log > * Possibly some stats/info from index files stored in tar files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-4934) Query shapes for JCR Query
[
https://issues.apache.org/jira/browse/OAK-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4934:
--
Fix Version/s: (was: 1.12.0)
> Query shapes for JCR Query
> --
>
> Key: OAK-4934
> URL: https://issues.apache.org/jira/browse/OAK-4934
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: query
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> For certain requirements it would be good to have a notion/support to deduce
> query shape [1]
> {quote}
> A combination of query predicate, sort, and projection specifications.
> For the query predicate, only the structure of the predicate, including the
> field names, are significant; the values in the query predicate are
> insignificant. As such, a query predicate \{ type: 'food' \} is equivalent to
> the query predicate \{ type: 'utensil' \} for a query shape.
> {quote}
> So transforming that to Oak the shape should represent a JCR-SQL2 query
> string (xpath query gets transformed to SQL2) which is a *canonical*
> representation of actual query ignoring the property restriction values.
> Example we have 2 queries
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'published'
> * SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] =
> 'disabled'
> The query shape would be
> SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'A'.
> The plan for query having given shape would remain same irrespective of value
> of property restrictions. Path restriction can cause some difference though
> The shape can then be used for
> * Stats Collection - Currently stats collection gets overflown if same query
> with different value gets invoked
> * Allow configuring hints - See support in Mongo [2] for an example. One
> specify via config that for a query of such and such shape this index should
> be used
> * Less noisy diagnostics - If a query gets invoked with bad plan the QE can
> log the warning once instead of logging it for each query invocation
> involving different values.
> [1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
> [2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4814) Add orderby support for nodename index
[ https://issues.apache.org/jira/browse/OAK-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4814: -- Fix Version/s: (was: 1.12.0) > Add orderby support for nodename index > -- > > Key: OAK-4814 > URL: https://issues.apache.org/jira/browse/OAK-4814 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Affects Versions: 1.5.10 >Reporter: Ankush Malhotra >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.14.0 > > > In OAK-1752 you have implemented the index support for :nodeName. The JCR > Query explain tool shows that it is used for conditions like equals. > But it is not used for ORDER BY name() . > Is name() supported in order by clause? If yes then we would need to add > support for that in oak-lucene -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3336: -- Fix Version/s: (was: 1.12.0) > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3717) Make it possible to declare SynonymFilter within Analyzer with WN dictionary
[
https://issues.apache.org/jira/browse/OAK-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3717:
--
Fix Version/s: (was: 1.12.0)
> Make it possible to declare SynonymFilter within Analyzer with WN dictionary
>
>
> Key: OAK-3717
> URL: https://issues.apache.org/jira/browse/OAK-3717
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently one can compose Lucene Analyzers via
> [composition|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Create_analyzer_via_composition]
> within an index definition. It'd be good to be able to also use
> {{SynonymFIlter}} in there, eventually decorated with
> {{WordNetSynonymParser}} to leverage WordNet synonym files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5897) Optimize like constraint support in Property Indexes
[
https://issues.apache.org/jira/browse/OAK-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5897:
--
Fix Version/s: (was: 1.12.0)
> Optimize like constraint support in Property Indexes
>
>
> Key: OAK-5897
> URL: https://issues.apache.org/jira/browse/OAK-5897
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Consider a query
> {noformat}
> /jcr:root/content//element(*, nt:unstructured)[jcr:like(@resource,
> '/content/foo/bar%')]
> {noformat}
> This currently gets translated into a range property restriction
> {noformat}
> property=[resource=[[/content/foo/bar.., ../content/foo/bas]]]
> {noformat}
> For such a query property index currently returns all nodes having "resource"
> property i.e. all index data. This can be optimized to return only those
> nodes where indexed value qualifies the range property restriction
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7207) Define porcelain and plumbing tools for the Segment Store
[ https://issues.apache.org/jira/browse/OAK-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7207: -- Fix Version/s: (was: 1.12.0) > Define porcelain and plumbing tools for the Segment Store > - > > Key: OAK-7207 > URL: https://issues.apache.org/jira/browse/OAK-7207 > Project: Jackrabbit Oak > Issue Type: Wish > Components: segment-tar >Reporter: Francesco Mari >Priority: Major > Labels: production, tooling > Fix For: 1.14.0 > > > In a spirit similar to > [Git|https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain]'s, > it would be beneficial to create porcelain and plumbing tooling for the > Segment Store. > Plumbing tools expose lower level operations on the Segment Store. Knowledge > about the internals of the Segment Store is necessary to understand how > plumbing tools work. Plumbing tools communicate via a command line interface. > It must be easy to invoke plumbing tools from other tools (possibly by > shelling out). The output of plumbing tools must be easy to consume > programmatically. > Porcelain tools are written for human consumption. Their interface must be > user-friendly and should be as much as possible backwards compatible. > Porcelain tools use plumbing ones to implement their features. It should be > possible to use the same porcelain tools with different versions of the > plumbing tools, as long as the plumbing tools "speak" through an interface > that remain sufficiently compatible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-3141) Oak should warn when too many ordered child nodes
[ https://issues.apache.org/jira/browse/OAK-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3141: -- Fix Version/s: (was: 1.12.0) > Oak should warn when too many ordered child nodes > - > > Key: OAK-3141 > URL: https://issues.apache.org/jira/browse/OAK-3141 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.16 >Reporter: Jörg Hoh >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.14.0 > > > When working with the RDBMK we came into situations, that large documents did > not fit into the provided db columns, there was an overflow, which caused oak > not to persist the change. We fixed it by increasing the size of the column. > But it would be nice if Oak could warn if a document exceeds a certain size > (for example 2 megabytes); because this warning indicates, that on a JCR > level there might be a problematic situation, for example: > * ordered node with a large list of childnodes > * or longstanding sessions with lots of changes, which accumulate to large > documents. > It's certainly nice to know if there's a node/document with such a problem, > before the exceptions actually happens and an operation breaks. > This message should be a warning, and should contain the JCR path of the node > plus the current size. To avoid that this message is overseen, it would be > good if it is written everyonce in a while (every 10 minutes?) if this > condition persists. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7372) Update FileDataStore recommendation
[ https://issues.apache.org/jira/browse/OAK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7372: -- Fix Version/s: (was: 1.12.0) > Update FileDataStore recommendation > --- > > Key: OAK-7372 > URL: https://issues.apache.org/jira/browse/OAK-7372 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0 > > > The BlobStore documentation currently mentions use of a FileDataStore only > for deployments when the data store is shared between multiple repository > instances. The documentation should be updated to also recommend the > FileDataStore when a repository has many binaries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
[ https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5144: -- Fix Version/s: (was: 1.12.0) > use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter > - > > Key: OAK-5144 > URL: https://issues.apache.org/jira/browse/OAK-5144 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.14 >Reporter: Stefan Egli >Priority: Major > Fix For: 1.14.0 > > > With OAK-4940 the ChangeSet now contains all node types up to root that are > related to a change. This fact could be used by the nodeType-aggregate-filter > (OAK-5021), which would likely speed up this type of filter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5121) review CommitInfo==null in BackgroundObserver with isExternal change
[ https://issues.apache.org/jira/browse/OAK-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5121: -- Fix Version/s: (was: 1.12.0) > review CommitInfo==null in BackgroundObserver with isExternal change > > > Key: OAK-5121 > URL: https://issues.apache.org/jira/browse/OAK-5121 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Affects Versions: 1.5.13 >Reporter: Stefan Egli >Assignee: Chetan Mehrotra >Priority: Major > Fix For: 1.14.0 > > Attachments: OAK-5121.patch > > > OAK-4898 changes CommitInfo to be never null. This is the case outside of the > BackgroundObserver - but in the BackgroundObserver itself it is explicitly > set to null when compacting. > Once OAK-4898 is committed this task is about reviewing the implications in > BackgroundObserver wrt compaction and CommitInfo==null -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7382) Cloud datastore without local disk
[ https://issues.apache.org/jira/browse/OAK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-7382: -- Fix Version/s: (was: 1.12.0) > Cloud datastore without local disk > -- > > Key: OAK-7382 > URL: https://issues.apache.org/jira/browse/OAK-7382 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob, blob-cloud >Reporter: Thomas Mueller >Assignee: Amit Jain >Priority: Major > Fix For: 1.14.0 > > > Currently, the S3 datastores need local disk to work (not sure about the > Azure one). > This should not be needed (not for upload, caching,...). > Also, temporary files for garbage collection should not be needed (instead, > use temporary binaries, possibly written to S3 / Azure). > Really everything should fit in a few MB of memory. > For S3, it might be needed to read a few MB of data into memory, and then > possibly do a multipart upload: > > https://stackoverflow.com/questions/8653146/can-i-stream-a-file-upload-to-s3-without-a-content-length-header -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5950) XPath: stack overflow for large combination of "or" and "and"
[
https://issues.apache.org/jira/browse/OAK-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5950:
--
Fix Version/s: (was: 1.12.0)
> XPath: stack overflow for large combination of "or" and "and"
> -
>
> Key: OAK-5950
> URL: https://issues.apache.org/jira/browse/OAK-5950
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> The following query returns in a stack overflow:
> {noformat}
> xpath2sql /jcr:root/home//element(*,rep:Authorizable)[(@a1=1 or @a2=1 or
> @a3=1 or @a4=1 or @a5=1 or @a6=1 or @a7=1 or @a8=1)
> and (@b1=1 or @b2=1 or @b3=1 or @b4=1 or @b5=1 or @b6=1 or @b7=1 or @b8=1)
> and (@c1=1 or @c2=1 or @c3=1 or @c4=1 or @c5=1 or @c6=1 or @c7=1 or @c8=1)
> and (@d1=1 or @d2=1 or @d3=1 or @d4=1 or @d5=1 or @d6=1 or @d7=1 or @d8=1)]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7425) Add discovery mechanism for tooling implementations
[
https://issues.apache.org/jira/browse/OAK-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-7425:
--
Fix Version/s: (was: 1.12.0)
> Add discovery mechanism for tooling implementations
> ---
>
> Key: OAK-7425
> URL: https://issues.apache.org/jira/browse/OAK-7425
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Labels: technical_debt
> Fix For: 1.14.0
>
> Attachments: 001.patch
>
>
> This issue proposes an idea for discovering implementations of tooling for
> the Segment Store. Developing a tool for the Segment Store should include the
> following step.
> * The tool compiles against the {{NodeStore}} API and the API exposed through
> the oak-segment-tar-tool-api. In particular, the tool uses the
> {{ToolingSupportFactory}} and related interfaces to instantiate a NodeStore
> and, optionally, a {{NodeState}} for the proc tree.
> * The tool runs with an implementation-dependent uber-jar in the classpath.
> The uber-jar includes the {{ToolingSupportFactory}} API, its implementation,
> and every other class required for the implementation to work. No other JARs
> is required to use the {{ToolingSupportFactory}} API. The tool uses the
> Java's {{ServiceLoader}} to instantiate an implementation of
> {{ToolingSupportFactory}}. The uber-jar is the {{oak-segment-tar-tool}}
> module.
> The patch falls short of fully implementing the use case because
> {{oak-segment-tar-tool-api}} is not versioned independently from Oak. This
> can't happen at the moment because {{oak-store-spi}} and its dependencies are
> not independently versioned either. The workflow described above could still
> work, but only because the {{NodeStore}} and {{NodeState}} API are quite
> stable. A cleaner solution to dependency management is required in the long
> run.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4524) LucenePropertyIndexTest#longRepExcerpt sometimes failing
[ https://issues.apache.org/jira/browse/OAK-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4524: -- Fix Version/s: (was: 1.12.0) > LucenePropertyIndexTest#longRepExcerpt sometimes failing > > > Key: OAK-4524 > URL: https://issues.apache.org/jira/browse/OAK-4524 > Project: Jackrabbit Oak > Issue Type: Test > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.14.0 > > > As reported by Julian on oak-dev@ it seems _longRepExcerpt_ is still failing > sometimes when query takes more than 10s e.g. see this [Jenkins > failure|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1000/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.lucene/LucenePropertyIndexTest/longRepExcerpt/]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
