[jira] [Created] (OAK-4344) LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity.
Manfred Baedke created OAK-4344: --- Summary: LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity. Key: OAK-4344 URL: https://issues.apache.org/jira/browse/OAK-4344 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Manfred Baedke Assignee: Manfred Baedke Priority: Minor Retrieving all attributes is usually unnecessary and may be costly. The current behavior should be the default, but it should also be possible to configure an explicit list of attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268743#comment-15268743
]
Alex Parvulescu commented on OAK-4165:
--
true. but that only applies to {{segment-next}}. we still have the old segment
impl in trunk, and that has not changed.
I think his original comment was along the lines of the initial approach to
merging the patch (overwrite the old segment impl), and this has changed (we
now have segment-next), so his comment doesn't apply.
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3981) Change in aggregation flow in OAK-3831 causes some properties to be left out of aggregation
[
https://issues.apache.org/jira/browse/OAK-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3981:
-
Labels: (was: docs-impacting)
> Change in aggregation flow in OAK-3831 causes some properties to be left out
> of aggregation
> ---
>
> Key: OAK-3981
> URL: https://issues.apache.org/jira/browse/OAK-3981
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.3.13, 1.0.26, 1.2.10
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.4, 1.2.11, 1.0.27, 1.3.16
>
>
> With OAK-3831 we change the aggregation logic to avoid indexing those
> relative properties for which there is a property definition defined but
> {{nodeScopeIndex}} is false.
> This causes regression as so far such properties were getting included via
> the aggregation rules and now they would be left out cause search to miss on
> those terms.
> As a fix we should revert to old logic and provide a new flag for enabling
> exclusion of property from getting aggregated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268733#comment-15268733
]
Francesco Mari commented on OAK-4165:
-
I decided to apply the patch directly to the 1.4 branch because of the
[~mduerig]'s comment. It seems that forward references are not computed anymore
because of OAK-3348.
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3981) Change in aggregation flow in OAK-3831 causes some properties to be left out of aggregation
[
https://issues.apache.org/jira/browse/OAK-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268732#comment-15268732
]
Chetan Mehrotra commented on OAK-3981:
--
Updated the docs in 1742112
> Change in aggregation flow in OAK-3831 causes some properties to be left out
> of aggregation
> ---
>
> Key: OAK-3981
> URL: https://issues.apache.org/jira/browse/OAK-3981
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.3.13, 1.0.26, 1.2.10
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.4, 1.2.11, 1.0.27, 1.3.16
>
>
> With OAK-3831 we change the aggregation logic to avoid indexing those
> relative properties for which there is a property definition defined but
> {{nodeScopeIndex}} is false.
> This causes regression as so far such properties were getting included via
> the aggregation rules and now they would be left out cause search to miss on
> those terms.
> As a fix we should revert to old logic and provide a new flag for enabling
> exclusion of property from getting aggregated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268698#comment-15268698
]
Alex Parvulescu commented on OAK-4165:
--
bq. Patch committed in r1742068.
I think this should have been applied to trunk and then merged. We still have
the {{oak-segment}} present on trunk, even if in maintenance mode only.
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4, 1.4.2
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4246) Update segment tooling to choose target store
[
https://issues.apache.org/jira/browse/OAK-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268652#comment-15268652
]
Francesco Mari commented on OAK-4246:
-
While working on this issue, I figured out that the amount of commands that
should be changed because of the introduction of {{oak-segment-tar}} is quite
high. Changing the commands is a very simple task but, most of the times,
commands implement their own argument parsing logic related to the creation of
a new {{NodeStore}}. Some code is duplicated from one command to another and
the same set of options is often repeated over and over.
I'm wondering if it could be easier to solve the problem once and for all by
unifying the {{NodeStore}} construction logic into a single component. This
component would construct instances of {{NodeStore}} from URIs passed on the
command line. When a different kind of {{NodeStore}} is required - e.g.
document- or segment-based - a different URI scheme should be used. In example:
- {{segment:///path/to/dir}} opens an "old style" segment store at the
specified folder.
- {{segment:tar:///path/to/dir}} opens a"new style" segment store at the
specified folder.
- {{segment:tar:///path/to/dir?mm=false}} opens a "new style" segment store at
the specified folder and disables memory mapped files.
Note that in the last two cases the URIs are actually layered: a first URI with
scheme {{segment}} is followed by another URI with scheme {{tar}}. This can be
very useful to define specific implementations of the same {{NodeStore}} family
by using nested schemes like {{segment:mem}}, {{document:mongo}},
{{document:rdb}}, and so on.
[~mduerig], [~alex.parvulescu], what do you think?
> Update segment tooling to choose target store
> -
>
> Key: OAK-4246
> URL: https://issues.apache.org/jira/browse/OAK-4246
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: tooling
> Fix For: 1.6, 1.5.2
>
>
> We need to add command line options segment specific tooling so users could
> chose between {{oak-segment}} and {{oak-segment-next}}. {{oak-segment}}
> should be the default until deprecated, where {{oak-segment-next}} should be
> made the default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4275) Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4
[ https://issues.apache.org/jira/browse/OAK-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268609#comment-15268609 ] Thomas Mueller commented on OAK-4275: - http://svn.apache.org/r1742108 (1.4 branch) > Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4 > > > Key: OAK-4275 > URL: https://issues.apache.org/jira/browse/OAK-4275 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.2, 1.2.15 > > > Even thought two workarounds exists (one is to rebuild the counter index, > another is to manually override the cost of an index), I think this needs to > be backported: > * Once it occurs, some queries are very slow, and it's not always easy to > understand why. > * The backport fixes the issue, and ensures people don't run into this issue > at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4275) Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4
[ https://issues.apache.org/jira/browse/OAK-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-4275. - Resolution: Fixed > Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4 > > > Key: OAK-4275 > URL: https://issues.apache.org/jira/browse/OAK-4275 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.2, 1.2.15 > > > Even thought two workarounds exists (one is to rebuild the counter index, > another is to manually override the cost of an index), I think this needs to > be backported: > * Once it occurs, some queries are very slow, and it's not always easy to > understand why. > * The backport fixes the issue, and ensures people don't run into this issue > at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4343) Add a flag to choose between segment store implementations in the "resetclusterid" command
Francesco Mari created OAK-4343: --- Summary: Add a flag to choose between segment store implementations in the "resetclusterid" command Key: OAK-4343 URL: https://issues.apache.org/jira/browse/OAK-4343 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "resetclusterid" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4342) Add a flag to choose between segment store implementations in the "dumpdatastorerefs" command
Francesco Mari created OAK-4342: --- Summary: Add a flag to choose between segment store implementations in the "dumpdatastorerefs" command Key: OAK-4342 URL: https://issues.apache.org/jira/browse/OAK-4342 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "dumpdatastorerefs" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4341) Add a flag to choose between segment store implementations in the "tarmkrecovery" command
Francesco Mari created OAK-4341: --- Summary: Add a flag to choose between segment store implementations in the "tarmkrecovery" command Key: OAK-4341 URL: https://issues.apache.org/jira/browse/OAK-4341 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "tarmkrecovery" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4340) Add a flag to choose between segment store implementations in the "tarmkdiff" command
Francesco Mari created OAK-4340: --- Summary: Add a flag to choose between segment store implementations in the "tarmkdiff" command Key: OAK-4340 URL: https://issues.apache.org/jira/browse/OAK-4340 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "tarmkdiff" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4339) Add a flag to choose between segment store implementations in the "tika" command
Francesco Mari created OAK-4339: --- Summary: Add a flag to choose between segment store implementations in the "tika" command Key: OAK-4339 URL: https://issues.apache.org/jira/browse/OAK-4339 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "tika" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4338) Add a flag to choose between segment store implementations in the "checkpoints" command
Francesco Mari created OAK-4338: --- Summary: Add a flag to choose between segment store implementations in the "checkpoints" command Key: OAK-4338 URL: https://issues.apache.org/jira/browse/OAK-4338 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "checkpoints" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4337) Add a flag to choose between segment store implementations in the "explore" command
Francesco Mari created OAK-4337: --- Summary: Add a flag to choose between segment store implementations in the "explore" command Key: OAK-4337 URL: https://issues.apache.org/jira/browse/OAK-4337 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "explore" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4275) Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4
[ https://issues.apache.org/jira/browse/OAK-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268554#comment-15268554 ] Thomas Mueller commented on OAK-4275: - http://svn.apache.org/r1742102 (1.2 branch) > Backport OAK-4065 (Counter index can get out of sync) to 1.2 and 1.4 > > > Key: OAK-4275 > URL: https://issues.apache.org/jira/browse/OAK-4275 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.2, 1.2.15 > > > Even thought two workarounds exists (one is to rebuild the counter index, > another is to manually override the cost of an index), I think this needs to > be backported: > * Once it occurs, some queries are very slow, and it's not always easy to > understand why. > * The backport fixes the issue, and ensures people don't run into this issue > at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4336) Add a flag to choose between segment store implementations in the "scalability" command
Francesco Mari created OAK-4336: --- Summary: Add a flag to choose between segment store implementations in the "scalability" command Key: OAK-4336 URL: https://issues.apache.org/jira/browse/OAK-4336 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "scalability" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4335) Add a flag to choose between segment store implementations in the "server" command
Francesco Mari created OAK-4335: --- Summary: Add a flag to choose between segment store implementations in the "server" command Key: OAK-4335 URL: https://issues.apache.org/jira/browse/OAK-4335 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "server" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4334) Add a flag to choose between segment store implementations in the "compact" command
Francesco Mari created OAK-4334: --- Summary: Add a flag to choose between segment store implementations in the "compact" command Key: OAK-4334 URL: https://issues.apache.org/jira/browse/OAK-4334 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "compact" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4332) Add a flag to choose between segment store implementations in the "history" command
Francesco Mari created OAK-4332: --- Summary: Add a flag to choose between segment store implementations in the "history" command Key: OAK-4332 URL: https://issues.apache.org/jira/browse/OAK-4332 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "history" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4333) Add a flag to choose between segment store implementations in the "check" command
Francesco Mari created OAK-4333: --- Summary: Add a flag to choose between segment store implementations in the "check" command Key: OAK-4333 URL: https://issues.apache.org/jira/browse/OAK-4333 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "check" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4331) Add a flag to choose between segment store implementations in the "graph" command
Francesco Mari created OAK-4331: --- Summary: Add a flag to choose between segment store implementations in the "graph" command Key: OAK-4331 URL: https://issues.apache.org/jira/browse/OAK-4331 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "graph" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4330) Add a flag to choose between segment store implementations in the "debug" command
Francesco Mari created OAK-4330: --- Summary: Add a flag to choose between segment store implementations in the "debug" command Key: OAK-4330 URL: https://issues.apache.org/jira/browse/OAK-4330 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "debug" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4329) Add a flag to choose between segment store implementations in the "console" command
Francesco Mari created OAK-4329: --- Summary: Add a flag to choose between segment store implementations in the "console" command Key: OAK-4329 URL: https://issues.apache.org/jira/browse/OAK-4329 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "console" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4327) Add a flag to choose between segment store implementations in the "restore" command
Francesco Mari created OAK-4327: --- Summary: Add a flag to choose between segment store implementations in the "restore" command Key: OAK-4327 URL: https://issues.apache.org/jira/browse/OAK-4327 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "restore" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4328) Add a flag to choose between segment store implementations in the "benchmark" command
Francesco Mari created OAK-4328: --- Summary: Add a flag to choose between segment store implementations in the "benchmark" command Key: OAK-4328 URL: https://issues.apache.org/jira/browse/OAK-4328 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "benchmark" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4326) Add a flag to choose between segment store implementations in the "backup" command
Francesco Mari created OAK-4326: --- Summary: Add a flag to choose between segment store implementations in the "backup" command Key: OAK-4326 URL: https://issues.apache.org/jira/browse/OAK-4326 Project: Jackrabbit Oak Issue Type: Technical task Components: run Reporter: Francesco Mari Assignee: Francesco Mari Fix For: 1.6 The "backup" command should provide a command line flag to choose between the new and old segment store implementations. If the flag is not provided, the old implementation must be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268462#comment-15268462 ] Thomas Mueller commented on OAK-4324: - http://svn.apache.org/r1742079 > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-4324. - Resolution: Fixed > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4325) Autocreation of properties fails if user id is null
[
https://issues.apache.org/jira/browse/OAK-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4325.
-
Resolution: Fixed
Fix Version/s: 1.5.2
Committed revision 1742077.
> Autocreation of properties fails if user id is null
> ---
>
> Key: OAK-4325
> URL: https://issues.apache.org/jira/browse/OAK-4325
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Reporter: angela
> Fix For: 1.5.2
>
>
> The currently implementation of {{TreeUtil.autoCreateItems}} will fail with
> {{RepositoryException}} if any of the autocreated properties could not be
> created. This is currently the case if the editing session doesn't have a
> userID set, which is a valid scenario.
> IMO the following autocreated properties should always be created and using
> an empty value if there is a null userID passed to the call:
> - jcr:createdBy
> - jcr:lastModifiedBy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4325) Autocreation of properties fails if user id is null
angela created OAK-4325:
---
Summary: Autocreation of properties fails if user id is null
Key: OAK-4325
URL: https://issues.apache.org/jira/browse/OAK-4325
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, jcr
Reporter: angela
The currently implementation of {{TreeUtil.autoCreateItems}} will fail with
{{RepositoryException}} if any of the autocreated properties could not be
created. This is currently the case if the editing session doesn't have a
userID set, which is a valid scenario.
IMO the following autocreated properties should always be created and using an
empty value if there is a null userID passed to the call:
- jcr:createdBy
- jcr:lastModifiedBy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4324: Fix Version/s: 1.2.15 > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4324: Component/s: query > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
Thomas Mueller created OAK-4324: --- Summary: Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2 Key: OAK-4324 URL: https://issues.apache.org/jira/browse/OAK-4324 Project: Jackrabbit Oak Issue Type: Bug Reporter: Thomas Mueller In additon to the bug described in OAK-3991, this is also a performance problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4324: Affects Version/s: 1.2 > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-4324) Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene full-text) to 1.2
[ https://issues.apache.org/jira/browse/OAK-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-4324: --- Assignee: Thomas Mueller > Backport OAK-3991 (Incorrect resultset from XPATH, multiple ORs and Lucene > full-text) to 1.2 > > > Key: OAK-4324 > URL: https://issues.apache.org/jira/browse/OAK-4324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Affects Versions: 1.2 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2.15 > > > In additon to the bug described in OAK-3991, this is also a performance > problem for XPath queries using many "jcr:contains" combined with "and". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4245) Decide on a final name for oak-segment-next
[
https://issues.apache.org/jira/browse/OAK-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4245.
-
Resolution: Fixed
{{oak-segment-next}} has been renamed to {{oak-segment-tar}} in r1742075.
> Decide on a final name for oak-segment-next
> ---
>
> Key: OAK-4245
> URL: https://issues.apache.org/jira/browse/OAK-4245
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Fix For: 1.6, 1.5.2
>
>
> We should come up with a definite and final name for {{oak-segment-name}}.
> Making this a blocker to avoid releasing with the current WIP name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (OAK-4245) Decide on a final name for oak-segment-next
[
https://issues.apache.org/jira/browse/OAK-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reopened OAK-4245:
-
Reopening to track the renaming of {{oak-segment=next}} to {{oak-segment-tar}}.
> Decide on a final name for oak-segment-next
> ---
>
> Key: OAK-4245
> URL: https://issues.apache.org/jira/browse/OAK-4245
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Fix For: 1.6, 1.5.2
>
>
> We should come up with a definite and final name for {{oak-segment-name}}.
> Making this a blocker to avoid releasing with the current WIP name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4245) Decide on a final name for oak-segment-next
[
https://issues.apache.org/jira/browse/OAK-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4245.
-
Resolution: Fixed
Assignee: Francesco Mari (was: Michael Dürig)
The vote was in favour of {{oak-segment-tar}}.
> Decide on a final name for oak-segment-next
> ---
>
> Key: OAK-4245
> URL: https://issues.apache.org/jira/browse/OAK-4245
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Fix For: 1.6, 1.5.2
>
>
> We should come up with a definite and final name for {{oak-segment-name}}.
> Making this a blocker to avoid releasing with the current WIP name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4318) Upgrade oak-solr to Solr 5.x
[ https://issues.apache.org/jira/browse/OAK-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-4318: - Attachment: OAK-4318.patch attached patch which upgrades Solr index to 5.5.0, I will measure performance against 1.4 (on Solr 4.7.1), however at a first glance indexing looks much faster (~5x faster). Size of _oak-solr-osgi_ is increased to 15.6MB vs 11.3MB in Oak 1.5.1 due to additional jackson and commons-exec dependencies (and Lucene itself got slightly bigger). > Upgrade oak-solr to Solr 5.x > > > Key: OAK-4318 > URL: https://issues.apache.org/jira/browse/OAK-4318 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.6 > > Attachments: OAK-4318.patch > > > Since we support JDK 1.7+ we can upgrade Solr to 5.x versions (not 6.0 as it > requires java 8 though). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4165) Too verbose logging during revision gc
[
https://issues.apache.org/jira/browse/OAK-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4165.
-
Resolution: Fixed
Patch committed in r1742068.
> Too verbose logging during revision gc
> --
>
> Key: OAK-4165
> URL: https://issues.apache.org/jira/browse/OAK-4165
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: cleanup, gc, logging
> Fix For: 1.4.2, 1.4
>
> Attachments: OAK_4165.patch
>
>
> {{FileStore.cleanup}} logs the segment id of any forward reference found when
> including those in the reference graph. The logged information can amount to
> several MBs impacting normal operation. Furthermore the actually reclaimed
> segments are logged, which also makes the log files explode. Finally the
> processing of the references and individual tar files might be too wordy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
