[jira] [Commented] (OAK-5448) Aggregate logic should optimize for case where patterns do not include wildcard
[
https://issues.apache.org/jira/browse/OAK-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822588#comment-15822588
]
Vikas Saurabh commented on OAK-5448:
[~chetanm], patch lgtm. Just a minor point though -
{{getElementNameIfNotAPattern}} feels like a {{getSomethingOrNull}} but it
throws instead.
> Aggregate logic should optimize for case where patterns do not include
> wildcard
> ---
>
> Key: OAK-5448
> URL: https://issues.apache.org/jira/browse/OAK-5448
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.5.18, 1.6
>
> Attachments: OAK-5448.patch
>
>
> Aggregate logic in oak-lucene currently tries to apply matcher on each of the
> child node of a modified parent node. This is required for those case where
> pattern involves wild card like aggregating '\*/\*/\*' pattern.
> However this performs poorly if the aggregate does not involve pattern. For
> e.g. if we have defined a property definition for 'jcr:content/@status' for
> nt:base
> {noformat}
> + indexRules
>+ nt:base
> + properties
> + status
> - name = "jcr:content/status"
> - propertyIndex = true
> {noformat}
> For above definition current logic would try to apply the matcher for
> 'jcr:content' on each of the child nodes. So if we have a folder have 1000
> entries it would read that many child nodes.
> As a fix we should check if the aggregate path has wild card or not. if its
> specific then aggregate logic should directly lookup child with given name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5417) Refactor registration of PropertyIndexAsyncReindex
[
https://issues.apache.org/jira/browse/OAK-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-5417.
--
Resolution: Fixed
Assignee: Alex Parvulescu
fixed with http://svn.apache.org/viewvc?rev=1778606=rev
> Refactor registration of PropertyIndexAsyncReindex
> --
>
> Key: OAK-5417
> URL: https://issues.apache.org/jira/browse/OAK-5417
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.5.18
>
> Attachments: OAK-5417.patch, OAK-5417-v2.patch
>
>
> Currently the {{PropertyIndexAsyncReindex}} is tied to the {{asyncTasks}}
> registration. I'd like to extract it to its own method, so this functionality
> can be enabled even if there are no specific async tasks registered (if the
> tasks are OSGi based for example).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4780) VersionGarbageCollector should be able to run incrementally
[ https://issues.apache.org/jira/browse/OAK-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821886#comment-15821886 ] Julian Reschke commented on OAK-4780: - Maybe we can shortcut certain operations for nodes where _children != true? In those cases, deletion order really doesn't matter, right? (We just counted nodes on a large instance, and approximately 1/3 of the nodes with _deletedOnce == true were leaf nodes) > VersionGarbageCollector should be able to run incrementally > --- > > Key: OAK-4780 > URL: https://issues.apache.org/jira/browse/OAK-4780 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke > > Right now, the documentmk's version garbage collection runs in several phases. > It first collects the paths of candidate nodes, and only once this has been > successfully finished, starts actually deleting nodes. > This can be a problem when the regularly scheduled garbage collection is > interrupted during the path collection phase, maybe due to other maintenance > tasks. On the next run, the number of paths to be collected will be even > bigger, thus making it even more likely to fail. > We should think about a change in the logic that would allow the GC to run in > chunks; maybe by partitioning the path space by top level directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5410) Backport OAK-5260 (Incorrect handling of subpaths with leading left curly bracket)
[ https://issues.apache.org/jira/browse/OAK-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5410. - Bulk close for 1.4.12 > Backport OAK-5260 (Incorrect handling of subpaths with leading left curly > bracket) > -- > > Key: OAK-5410 > URL: https://issues.apache.org/jira/browse/OAK-5410 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.12 > > > See OAK-5260 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-5260) Incorrect handling of subpaths with leading left curly bracket
[
https://issues.apache.org/jira/browse/OAK-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-5260.
-
Bulk close for 1.4.12
> Incorrect handling of subpaths with leading left curly bracket
> --
>
> Key: OAK-5260
> URL: https://issues.apache.org/jira/browse/OAK-5260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Bertrand Delacretaz
>Assignee: Thomas Mueller
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.4.12, 1.5.17, 1.6
>
> Attachments: OAK-5260-jsedding.patch, OAK-5260.patch
>
>
> As per SLING-6383 it looks like the Oak name mapping causes for example
> getItem("/libs/{sub") (with a left curly bracket in the path) to return the
> /libs node if that exists but the supplied path does not.
> I'll attach a patch with a test that demonstrates this.
> [~fmeschbe] mentions in that Sling issue that the parsing of the CR 2 section
> 3.2.5.1 Expanded Form could be involved, treating the left curly bracket in a
> special way that's not appropriate here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5290) Backport the performance improvements for oak-upgrade from trunk
[ https://issues.apache.org/jira/browse/OAK-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-5290. - Bulk close for 1.4.12 > Backport the performance improvements for oak-upgrade from trunk > > > Key: OAK-5290 > URL: https://issues.apache.org/jira/browse/OAK-5290 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: upgrade >Reporter: Tomek Rękawek > Fix For: 1.4.12 > > > oak-upgrade will be used in 1.6 to migrate old oak-segment to the new > oak-segment-tar. During the process it was well tested by [~mduerig] and > [~alex.parvulescu], which resulted in many performance improvements. They > should be backported to 1.4 as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-5447) reduce VersionGarbageCollector/StringSort temporary space requirements
[
https://issues.apache.org/jira/browse/OAK-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5447:
Attachment: OAK-5447.diff
Proposed patch; checked in unit tests by hacking the overFlowThreshold - which
makes me wonder whether it's a good idea to have two different code paths in
the first place.
> reduce VersionGarbageCollector/StringSort temporary space requirements
> --
>
> Key: OAK-5447
> URL: https://issues.apache.org/jira/browse/OAK-5447
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Julian Reschke
>Priority: Minor
> Labels: patch-available
> Attachments: OAK-5447.diff
>
>
> When using {{ExternalSort}}, the code temporarily needs 2 * the size of the
> file to be sorted (on disk).
> That might be hard to avoid, but once the file is sorted, the unsorted one
> could be removed. (Right now, it cleans up everything in one go at the end)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5447) reduce VersionGarbageCollector/StringSort temporary space requirements
[
https://issues.apache.org/jira/browse/OAK-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5447:
Component/s: (was: core)
documentmk
> reduce VersionGarbageCollector/StringSort temporary space requirements
> --
>
> Key: OAK-5447
> URL: https://issues.apache.org/jira/browse/OAK-5447
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
> Labels: patch-available
> Attachments: OAK-5447.diff
>
>
> When using {{ExternalSort}}, the code temporarily needs 2 * the size of the
> file to be sorted (on disk).
> That might be hard to avoid, but once the file is sorted, the unsorted one
> could be removed. (Right now, it cleans up everything in one go at the end)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5447) reduce VersionGarbageCollector/StringSort temporary space requirements
[
https://issues.apache.org/jira/browse/OAK-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-5447:
Labels: patch-available (was: )
> reduce VersionGarbageCollector/StringSort temporary space requirements
> --
>
> Key: OAK-5447
> URL: https://issues.apache.org/jira/browse/OAK-5447
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Julian Reschke
>Priority: Minor
> Labels: patch-available
>
> When using {{ExternalSort}}, the code temporarily needs 2 * the size of the
> file to be sorted (on disk).
> That might be hard to avoid, but once the file is sorted, the unsorted one
> could be removed. (Right now, it cleans up everything in one go at the end)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5210) Ability to resolve principal name from ExternalIdentityRef without IDP roundtrip
[
https://issues.apache.org/jira/browse/OAK-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821446#comment-15821446
]
angela commented on OAK-5210:
-
[~baedke], [~tripod], any review findings or objections from your side?
alternative approaches? If not I would continue working on this approach.
> Ability to resolve principal name from ExternalIdentityRef without IDP
> roundtrip
>
>
> Key: OAK-5210
> URL: https://issues.apache.org/jira/browse/OAK-5210
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Attachments: OAK-5210-initialdraft.patch
>
>
> Currently the only way to reliably determine the principal name for a given
> external identity is by calling {{ExternalIdentity.getPrincipalName()}}. This
> also means that there is currently no way to resolve the principal name from
> a given {{ExternalIdentityRef}}, without calling
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}.
> In the default sync mode a given identity-ref will always be resolved to the
> associated identity once a given identity is up for (re)sync and thus the
> identity resolution is part of the synchronization. On the other hand the
> partial sync as provided by the {{DynamicSyncContext}} doesn't require the
> resolution of group identities but only needs to be able to obtain the
> principal name, which is needed to proper populate the subject upon
> repository login (and for permission setup for those group principals). In
> this setup it would be preferrable if the principal name could be resolved
> from the {{ExternalIdentityRef}} without the intermediate identity resolution.
> This aim of this issue is to discuss the different options on how to achieve
> this improvement in a generic way that doesn't make any assumptions regarding
> the relationship between {{ExternalIdentity.getId}},
> {{ExternalIdentity.getPrincipalName}} and {{ExternalIdentityRef.getId}}.
> See also OAK-4930 and OAK-5200 for additional information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-5262) Test failure: NodeTypeIndexingUtilsTest.testSynonymsFileCreation
[ https://issues.apache.org/jira/browse/OAK-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain closed OAK-5262. -- > Test failure: NodeTypeIndexingUtilsTest.testSynonymsFileCreation > > > Key: OAK-5262 > URL: https://issues.apache.org/jira/browse/OAK-5262 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, solr >Affects Versions: 1.5.15, 1.4.11 >Reporter: Hudson >Assignee: Marcel Reutegger > Fix For: 1.5.17, 1.2.23, 1.4.12, 1.6 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=DOCUMENT_RDB,profile=unittesting #1322 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_RDB,profile=unittesting > #1322|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_RDB,profile=unittesting/1322/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_RDB,profile=unittesting/1322/console] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5448) Aggregate logic should optimize for case where patterns do not include wildcard
Chetan Mehrotra created OAK-5448:
Summary: Aggregate logic should optimize for case where patterns
do not include wildcard
Key: OAK-5448
URL: https://issues.apache.org/jira/browse/OAK-5448
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: 1.5.18, 1.6
Aggregate logic in oak-lucene currently tries to apply matcher on each of the
child node of a modified parent node. This is required for those case where
pattern involves wild card like aggregating '*/*/*' pattern.
However this performs poorly if the aggregate does not involve pattern. For
e.g. if we have defined a property definition for 'jcr:content/@status' for
nt:base
{noformat}
+ indexRules
+ nt:base
+ properties
+ status
- name = "jcr:content/status"
- propertyIndex = true
{noformat}
For above definition current logic would try to apply the matcher for
'jcr:content' on each of the child nodes. So if we have a folder have 1000
entries it would read that many child nodes.
As a fix we should check if the aggregate path has wild card or not. if its
specific then aggregate logic should directly lookup child with given name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5448) Aggregate logic should optimize for case where patterns do not include wildcard
[
https://issues.apache.org/jira/browse/OAK-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-5448:
-
Description:
Aggregate logic in oak-lucene currently tries to apply matcher on each of the
child node of a modified parent node. This is required for those case where
pattern involves wild card like aggregating '\*/\*/\*' pattern.
However this performs poorly if the aggregate does not involve pattern. For
e.g. if we have defined a property definition for 'jcr:content/@status' for
nt:base
{noformat}
+ indexRules
+ nt:base
+ properties
+ status
- name = "jcr:content/status"
- propertyIndex = true
{noformat}
For above definition current logic would try to apply the matcher for
'jcr:content' on each of the child nodes. So if we have a folder have 1000
entries it would read that many child nodes.
As a fix we should check if the aggregate path has wild card or not. if its
specific then aggregate logic should directly lookup child with given name
was:
Aggregate logic in oak-lucene currently tries to apply matcher on each of the
child node of a modified parent node. This is required for those case where
pattern involves wild card like aggregating '*/*/*' pattern.
However this performs poorly if the aggregate does not involve pattern. For
e.g. if we have defined a property definition for 'jcr:content/@status' for
nt:base
{noformat}
+ indexRules
+ nt:base
+ properties
+ status
- name = "jcr:content/status"
- propertyIndex = true
{noformat}
For above definition current logic would try to apply the matcher for
'jcr:content' on each of the child nodes. So if we have a folder have 1000
entries it would read that many child nodes.
As a fix we should check if the aggregate path has wild card or not. if its
specific then aggregate logic should directly lookup child with given name
> Aggregate logic should optimize for case where patterns do not include
> wildcard
> ---
>
> Key: OAK-5448
> URL: https://issues.apache.org/jira/browse/OAK-5448
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.5.18, 1.6
>
>
> Aggregate logic in oak-lucene currently tries to apply matcher on each of the
> child node of a modified parent node. This is required for those case where
> pattern involves wild card like aggregating '\*/\*/\*' pattern.
> However this performs poorly if the aggregate does not involve pattern. For
> e.g. if we have defined a property definition for 'jcr:content/@status' for
> nt:base
> {noformat}
> + indexRules
>+ nt:base
> + properties
> + status
> - name = "jcr:content/status"
> - propertyIndex = true
> {noformat}
> For above definition current logic would try to apply the matcher for
> 'jcr:content' on each of the child nodes. So if we have a folder have 1000
> entries it would read that many child nodes.
> As a fix we should check if the aggregate path has wild card or not. if its
> specific then aggregate logic should directly lookup child with given name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5448) Aggregate logic should optimize for case where patterns do not include wildcard
[
https://issues.apache.org/jira/browse/OAK-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-5448:
-
Attachment: OAK-5448.patch
[patch|^OAK-5448.patch] for the same
[~catholicon] Can you review once!
> Aggregate logic should optimize for case where patterns do not include
> wildcard
> ---
>
> Key: OAK-5448
> URL: https://issues.apache.org/jira/browse/OAK-5448
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.5.18, 1.6
>
> Attachments: OAK-5448.patch
>
>
> Aggregate logic in oak-lucene currently tries to apply matcher on each of the
> child node of a modified parent node. This is required for those case where
> pattern involves wild card like aggregating '\*/\*/\*' pattern.
> However this performs poorly if the aggregate does not involve pattern. For
> e.g. if we have defined a property definition for 'jcr:content/@status' for
> nt:base
> {noformat}
> + indexRules
>+ nt:base
> + properties
> + status
> - name = "jcr:content/status"
> - propertyIndex = true
> {noformat}
> For above definition current logic would try to apply the matcher for
> 'jcr:content' on each of the child nodes. So if we have a folder have 1000
> entries it would read that many child nodes.
> As a fix we should check if the aggregate path has wild card or not. if its
> specific then aggregate logic should directly lookup child with given name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5448) Aggregate logic should optimize for case where patterns do not include wildcard
[
https://issues.apache.org/jira/browse/OAK-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821521#comment-15821521
]
Chetan Mehrotra commented on OAK-5448:
--
Added ignored test in 1778520
> Aggregate logic should optimize for case where patterns do not include
> wildcard
> ---
>
> Key: OAK-5448
> URL: https://issues.apache.org/jira/browse/OAK-5448
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.5.18, 1.6
>
>
> Aggregate logic in oak-lucene currently tries to apply matcher on each of the
> child node of a modified parent node. This is required for those case where
> pattern involves wild card like aggregating '*/*/*' pattern.
> However this performs poorly if the aggregate does not involve pattern. For
> e.g. if we have defined a property definition for 'jcr:content/@status' for
> nt:base
> {noformat}
> + indexRules
>+ nt:base
> + properties
> + status
> - name = "jcr:content/status"
> - propertyIndex = true
> {noformat}
> For above definition current logic would try to apply the matcher for
> 'jcr:content' on each of the child nodes. So if we have a folder have 1000
> entries it would read that many child nodes.
> As a fix we should check if the aggregate path has wild card or not. if its
> specific then aggregate logic should directly lookup child with given name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5449) Cost calculation for one matching property restriction/sorting results in selection of wrong index
Volker Schmidt created OAK-5449:
---
Summary: Cost calculation for one matching property
restriction/sorting results in selection of wrong index
Key: OAK-5449
URL: https://issues.apache.org/jira/browse/OAK-5449
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Affects Versions: 1.4.10
Reporter: Volker Schmidt
The method IndexPlanner.getPlanBuilder() for Lucene indexes contains at the end
an algorithm that calculates a costPerEntryFactory. If there is no restriction
property or sort property the factory will be the same like for one restriction
property or sort property.
If there are two indexes for which the cost is calculated, the cost must not be
the same. E.g. if there is a large result set that can be sorted with one index
but not with the other index, the index that supports sorting should be used.
The following code snippet:
if (costPerEntryFactor == 0) {
costPerEntryFactor = 1;
}
should be changed to something like this (assuming costPerEntryFactor will be
changed to double value and will be rounded after division at the end of the
method):
if (costPerEntryFactor == 1.0) {
// one matching restriction or sort property
costPerEntryFactor = 1.5;
}
else if (costPerEntryFactor == 0.0) {
// no matching restriction or sort property
costPerEntryFactor = 1.0;
}
Furthermore, since the found indexes are stored in a hashed collection, the
order of the index evaluation and the resulting index (when cost is the same
for more than one lucene based index) is non deterministic. This increases the
issue with the code above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5450) Documented example for relativeNode in index aggregation does not work.
Volker Schmidt created OAK-5450: --- Summary: Documented example for relativeNode in index aggregation does not work. Key: OAK-5450 URL: https://issues.apache.org/jira/browse/OAK-5450 Project: Jackrabbit Oak Issue Type: Bug Components: examples, lucene Affects Versions: 1.4.10 Reporter: Volker Schmidt Priority: Minor The documentation contains the following example query: select * from [app:Asset] where contains(renditions/original/*, "pluto") This query does not work. The parser identifies the pattern /* as begin of a comment and does not find the end of the comment. The following query works: select * from [app:Asset] where contains([renditions/original/*], "pluto") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5451) Class IndexTracker should not be package protected since LuceneIndexMBeanImpl cannot be used in non OSGi configurations
Volker Schmidt created OAK-5451: --- Summary: Class IndexTracker should not be package protected since LuceneIndexMBeanImpl cannot be used in non OSGi configurations Key: OAK-5451 URL: https://issues.apache.org/jira/browse/OAK-5451 Project: Jackrabbit Oak Issue Type: Bug Components: lucene Affects Versions: 1.4.10 Reporter: Volker Schmidt Priority: Minor Class IndexTracker is a package protected class that must be passed as an argument to LuceneIndexMBeanImpl. For OSGi environments the MBean LuceneIndexMBeanImpl is registered by LuceneIndexProviderService that is located in the same package like IndexTracker. For nin OSGi environments LuceneIndexMBeanImpl cannot be used, since class IndexTracker is not accessible (except by implementing workarounds). Either class IndexTracker should be public or the constructor argument of LuceneIndexMBeanImpl should be LuceneIndexProvider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5452) Fix typo in CheckpointMBean type value
Alex Parvulescu created OAK-5452:
Summary: Fix typo in CheckpointMBean type value
Key: OAK-5452
URL: https://issues.apache.org/jira/browse/OAK-5452
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Priority: Trivial
Fix For: 1.5.18
Rename type from {{CheckpointManger}} to {{CheckpointManager}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5416) Async reindex of a sync property does't release created checkpoint
[ https://issues.apache.org/jira/browse/OAK-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-5416. -- Resolution: Fixed fixed with http://svn.apache.org/viewvc?rev=1778620=rev I opted to not add any cleanup support. that can already be done via the CheckpointManager mbean, so I only updated the docs with what needs to be done in the case of a failed async reindex. If this does not suffice we can have another look at the resiliency aspect later. > Async reindex of a sync property does't release created checkpoint > -- > > Key: OAK-5416 > URL: https://issues.apache.org/jira/browse/OAK-5416 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > Fix For: 1.5.18 > > Attachments: OAK-5416.patch, OAK-5416-v2.patch, OAK-5416-v3.patch > > > Async reindex of a property index creates a checkpoint to use as a reference, > but it fails to clean it up when done. In the usual reindexing scenario the > async indexer needs to keep the created checkpoint as a reference for > subsequent runs, but this is a 'one off' case, so cleanup of this reference > checkpoint must also happen at the end of the cycle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5452) Fix typo in CheckpointMBean type value
[
https://issues.apache.org/jira/browse/OAK-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821923#comment-15821923
]
Alex Parvulescu commented on OAK-5452:
--
{noformat}
org.apache.jackrabbit.oak.api.jmx: Version increase required; detected 4.4.1,
suggested 4.4.2
{noformat}
hmm, [~edivad] can I safely do this so close to the release?
> Fix typo in CheckpointMBean type value
> --
>
> Key: OAK-5452
> URL: https://issues.apache.org/jira/browse/OAK-5452
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Trivial
> Fix For: 1.5.18
>
>
> Rename type from {{CheckpointManger}} to {{CheckpointManager}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
