[jira] [Created] (OAK-4806) Remove usage of Tree in LuceneIndexEditor
Chetan Mehrotra created OAK-4806:
Summary: Remove usage of Tree in LuceneIndexEditor
Key: OAK-4806
URL: https://issues.apache.org/jira/browse/OAK-4806
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: 1.6
{{LuceneIndexEditor}} currently creates 2 tree instances for determining
IndexRule. [~ianeboston] highlighted this on list [1] and this is something
which we should avoid and remove usage of Tree api
This was earlier done so as to simplify future support for conditional rules
(OAK-2281) which might need access to ancestor which is not possible with
NodeState api. As that is not going to be done so we can get rid of Tree
construction in the editor.
[1]
https://lists.apache.org/thread.html/7d51b45296f5801c3b510a30a4847ce297707fb4e0d4c2cefe19be62@%3Coak-dev.jackrabbit.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4805) Misconfigured lucene index definition can render the whole system unusable
[
https://issues.apache.org/jira/browse/OAK-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491567#comment-15491567
]
Vikas Saurabh edited comment on OAK-4805 at 9/14/16 10:01 PM:
--
[~chetanm], can you please take a look at [^OAK-4805.patch] if it's the right
place to catch and log the exception. I've not update {{LuceneIndex.java}}
though (wasn't sure if we want to maintain that or not).
was (Author: catholicon):
[~chetanm], can you please take a look if it's the right place to catch and log
the exception. I've not update {{LuceneIndex.java}} though (wasn't sure if we
want to maintain that or not).
> Misconfigured lucene index definition can render the whole system unusable
> --
>
> Key: OAK-4805
> URL: https://issues.apache.org/jira/browse/OAK-4805
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6
>
> Attachments: OAK-4805.patch
>
>
> Mis-configured index definition can throw an exception while collecting
> plans. This causes any query (even unrelated ones) to not work as cost
> calculation logic would consult a badly constructed index def. Overall a
> mis-configured index definition can practically grind the whole system to
> halt as the whole query framework stops working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4805) Misconfigured lucene index definition can render the whole system unusable
[ https://issues.apache.org/jira/browse/OAK-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4805: --- Flags: Patch > Misconfigured lucene index definition can render the whole system unusable > -- > > Key: OAK-4805 > URL: https://issues.apache.org/jira/browse/OAK-4805 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.6 > > Attachments: OAK-4805.patch > > > Mis-configured index definition can throw an exception while collecting > plans. This causes any query (even unrelated ones) to not work as cost > calculation logic would consult a badly constructed index def. Overall a > mis-configured index definition can practically grind the whole system to > halt as the whole query framework stops working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4805) Misconfigured lucene index definition can render the whole system unusable
[
https://issues.apache.org/jira/browse/OAK-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4805:
---
Attachment: OAK-4805.patch
[~chetanm], can you please take a look if it's the right place to catch and log
the exception. I've not update {{LuceneIndex.java}} though (wasn't sure if we
want to maintain that or not).
> Misconfigured lucene index definition can render the whole system unusable
> --
>
> Key: OAK-4805
> URL: https://issues.apache.org/jira/browse/OAK-4805
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.6
>
> Attachments: OAK-4805.patch
>
>
> Mis-configured index definition can throw an exception while collecting
> plans. This causes any query (even unrelated ones) to not work as cost
> calculation logic would consult a badly constructed index def. Overall a
> mis-configured index definition can practically grind the whole system to
> halt as the whole query framework stops working.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4805) Misconfigured lucene index definition can render the whole system unusable
[ https://issues.apache.org/jira/browse/OAK-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4805: --- Summary: Misconfigured lucene index definition can render the whole system unusable (was: Misconfigured lucene index definition can make the whole system unusable) > Misconfigured lucene index definition can render the whole system unusable > -- > > Key: OAK-4805 > URL: https://issues.apache.org/jira/browse/OAK-4805 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh > Fix For: 1.6 > > > Mis-configured index definition can throw an exception while collecting > plans. This causes any query (even unrelated ones) to not work as cost > calculation logic would consult a badly constructed index def. Overall a > mis-configured index definition can practically grind the whole system to > halt as the whole query framework stops working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4805) Misconfigured lucene index definition can make the whole system unusable
Vikas Saurabh created OAK-4805: -- Summary: Misconfigured lucene index definition can make the whole system unusable Key: OAK-4805 URL: https://issues.apache.org/jira/browse/OAK-4805 Project: Jackrabbit Oak Issue Type: Bug Components: lucene Reporter: Vikas Saurabh Assignee: Vikas Saurabh Fix For: 1.6 Mis-configured index definition can throw an exception while collecting plans. This causes any query (even unrelated ones) to not work as cost calculation logic would consult a badly constructed index def. Overall a mis-configured index definition can practically grind the whole system to halt as the whole query framework stops working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4804) Synonym analyzer with multiple words in synonym definition can give more results than expected
[
https://issues.apache.org/jira/browse/OAK-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4804:
---
Summary: Synonym analyzer with multiple words in synonym definition can
give more results than expected (was: Synonym with multiple words can give
more results than expected)
> Synonym analyzer with multiple words in synonym definition can give more
> results than expected
> --
>
> Key: OAK-4804
> URL: https://issues.apache.org/jira/browse/OAK-4804
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> Setting up synonyms such as {{"FTW, For the win"}} would also return
> documents which contain all of {{"For", "the", "win"}}.
> Test case:
> {noformat}
> @Test
> public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
> Tree idx = createFulltextIndex(root.getTree("/"), "test");
> TestUtil.useV2(idx);
> Tree anl =
> idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
>
> anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
> "Standard");
> Tree synFilter =
> anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
> synFilter.setProperty("synonyms", "syn.txt");
>
> synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA,
> "FTW, For the win");
> Tree test = root.getTree("/").addChild("test");
> test.addChild("1").setProperty("foo", "FTW");
> test.addChild("2").setProperty("foo", "For the win");
> test.addChild("3").setProperty("foo", "For gods sake, this is not the
> way to win it");
> root.commit();
> assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
> ISDESCENDANTNODE('/test')",
> asList("/test/1", "/test/2"));//current (failing result is
> ["/test/1", "/test/2", "/test/3"])
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4804) Synonym with multiple words can give more results than expected
[
https://issues.apache.org/jira/browse/OAK-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4804:
---
Summary: Synonym with multiple words can give more results than expected
(was: Synonym with multiple words give more results than expected)
> Synonym with multiple words can give more results than expected
> ---
>
> Key: OAK-4804
> URL: https://issues.apache.org/jira/browse/OAK-4804
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> Setting up synonyms such as {{"FTW, For the win"}} would also return
> documents which contain all of {{"For", "the", "win"}}.
> Test case:
> {noformat}
> @Test
> public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
> Tree idx = createFulltextIndex(root.getTree("/"), "test");
> TestUtil.useV2(idx);
> Tree anl =
> idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
>
> anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
> "Standard");
> Tree synFilter =
> anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
> synFilter.setProperty("synonyms", "syn.txt");
>
> synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA,
> "FTW, For the win");
> Tree test = root.getTree("/").addChild("test");
> test.addChild("1").setProperty("foo", "FTW");
> test.addChild("2").setProperty("foo", "For the win");
> test.addChild("3").setProperty("foo", "For gods sake, this is not the
> way to win it");
> root.commit();
> assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
> ISDESCENDANTNODE('/test')",
> asList("/test/1", "/test/2"));//current (failing result is
> ["/test/1", "/test/2", "/test/3"])
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4804) Synonym with multiple words give more results than expected
[
https://issues.apache.org/jira/browse/OAK-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4804:
---
Description:
Setting up synonyms such as {{"FTW, For the win"}} would also return documents
which contain all of {{"For", "the", "win"}}.
Test case:
{noformat}
@Test
public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
Tree idx = createFulltextIndex(root.getTree("/"), "test");
TestUtil.useV2(idx);
Tree anl =
idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
"Standard");
Tree synFilter =
anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
synFilter.setProperty("synonyms", "syn.txt");
synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA, "FTW,
For the win");
Tree test = root.getTree("/").addChild("test");
test.addChild("1").setProperty("foo", "FTW");
test.addChild("2").setProperty("foo", "For the win");
test.addChild("3").setProperty("foo", "For gods sake, this is not the
way to win it");
root.commit();
assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
ISDESCENDANTNODE('/test')",
asList("/test/1", "/test/2"));//current (failing result is
["/test/1", "/test/2", "/test/3"])
}
{noformat}
was:
Setting up synonyms such as {{"FTW, For the win"}} would also return documents
which contain all of {{"For", "the", "win"}}.
Test case:
{noformat}
@Test
public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
Tree idx = createFulltextIndex(root.getTree("/"), "test");
TestUtil.useV2(idx);
Tree anl =
idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
"Standard");
Tree synFilter =
anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
synFilter.setProperty("synonyms", "syn.txt");
synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA, "FTW,
For the win");
Tree test = root.getTree("/").addChild("test");
test.addChild("1").setProperty("foo", "FTW");
test.addChild("2").setProperty("foo", "For the win");
test.addChild("3").setProperty("foo", "For gods sake, this is not the
way to win it");
root.commit();
assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
ISDESCENDANTNODE('/test')",
asList("/test/1", "/test/2"));
}
{noformat}
> Synonym with multiple words give more results than expected
> ---
>
> Key: OAK-4804
> URL: https://issues.apache.org/jira/browse/OAK-4804
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> Setting up synonyms such as {{"FTW, For the win"}} would also return
> documents which contain all of {{"For", "the", "win"}}.
> Test case:
> {noformat}
> @Test
> public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
> Tree idx = createFulltextIndex(root.getTree("/"), "test");
> TestUtil.useV2(idx);
> Tree anl =
> idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
>
> anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
> "Standard");
> Tree synFilter =
> anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
> synFilter.setProperty("synonyms", "syn.txt");
>
> synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA,
> "FTW, For the win");
> Tree test = root.getTree("/").addChild("test");
> test.addChild("1").setProperty("foo", "FTW");
> test.addChild("2").setProperty("foo", "For the win");
> test.addChild("3").setProperty("foo", "For gods sake, this is not the
> way to win it");
> root.commit();
> assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
> ISDESCENDANTNODE('/test')",
> asList("/test/1", "/test/2"));//current (failing result is
> ["/test/1", "/test/2", "/test/3"])
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4804) Synonym with multiple words give more results than expected
[
https://issues.apache.org/jira/browse/OAK-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490884#comment-15490884
]
Vikas Saurabh commented on OAK-4804:
This is closely related to point 2 mentioned in
https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory.
In current scheme of things, it doesn't quite affect much because we use same
analyzer on both indexing and querying side - so no result is missing BUT we
get more results... albeit the unexpected result would usually be ranked lower.
The only way that I can think of fixing this is to allow for different analyzer
for index and querying time.
[~chetanm], [~teofili], thoughts?
> Synonym with multiple words give more results than expected
> ---
>
> Key: OAK-4804
> URL: https://issues.apache.org/jira/browse/OAK-4804
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> Setting up synonyms such as {{"FTW, For the win"}} would also return
> documents which contain all of {{"For", "the", "win"}}.
> Test case:
> {noformat}
> @Test
> public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
> Tree idx = createFulltextIndex(root.getTree("/"), "test");
> TestUtil.useV2(idx);
> Tree anl =
> idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
>
> anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
> "Standard");
> Tree synFilter =
> anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
> synFilter.setProperty("synonyms", "syn.txt");
>
> synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA,
> "FTW, For the win");
> Tree test = root.getTree("/").addChild("test");
> test.addChild("1").setProperty("foo", "FTW");
> test.addChild("2").setProperty("foo", "For the win");
> test.addChild("3").setProperty("foo", "For gods sake, this is not the
> way to win it");
> root.commit();
> assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
> ISDESCENDANTNODE('/test')",
> asList("/test/1", "/test/2"));
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4804) Synonym with multiple words give more results than expected
Vikas Saurabh created OAK-4804:
--
Summary: Synonym with multiple words give more results than
expected
Key: OAK-4804
URL: https://issues.apache.org/jira/browse/OAK-4804
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
Priority: Minor
Setting up synonyms such as {{"FTW, For the win"}} would also return documents
which contain all of {{"For", "the", "win"}}.
Test case:
{noformat}
@Test
public void fulltextSearchWithPhraseSynonymAnalyzer() throws Exception {
Tree idx = createFulltextIndex(root.getTree("/"), "test");
TestUtil.useV2(idx);
Tree anl =
idx.addChild(LuceneIndexConstants.ANALYZERS).addChild(LuceneIndexConstants.ANL_DEFAULT);
anl.addChild(LuceneIndexConstants.ANL_TOKENIZER).setProperty(LuceneIndexConstants.ANL_NAME,
"Standard");
Tree synFilter =
anl.addChild(LuceneIndexConstants.ANL_FILTERS).addChild("Synonym");
synFilter.setProperty("synonyms", "syn.txt");
synFilter.addChild("syn.txt").addChild(JCR_CONTENT).setProperty(JCR_DATA, "FTW,
For the win");
Tree test = root.getTree("/").addChild("test");
test.addChild("1").setProperty("foo", "FTW");
test.addChild("2").setProperty("foo", "For the win");
test.addChild("3").setProperty("foo", "For gods sake, this is not the
way to win it");
root.commit();
assertQuery("select * from [nt:base] where CONTAINS(*, 'FTW') AND
ISDESCENDANTNODE('/test')",
asList("/test/1", "/test/2"));
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4793) Check usage of DocumentStoreException in RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4793: Attachment: OAK-4793-2.diff work in progress (handling of DocumentStoreException in db.delete needs to be restored) > Check usage of DocumentStoreException in RDBDocumentStore > - > > Key: OAK-4793 > URL: https://issues.apache.org/jira/browse/OAK-4793 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, rdbmk >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4793-1.diff, OAK-4793-2.diff, OAK-4793.diff, > OAK-4793.diff > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in RDBDocumentStore and make sure JDBC driver specific > exceptions are handled consistently and wrapped in a DocumentStoreException. > At the same time, cache consistency needs to be checked as well in case of a > driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4580) Update to Mongo Java Driver 3.2.x
[ https://issues.apache.org/jira/browse/OAK-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490551#comment-15490551 ] Marcel Reutegger commented on OAK-4580: --- Updated the import package directive to make sure the com.mongodb packages are optional: http://svn.apache.org/r1760715 > Update to Mongo Java Driver 3.2.x > - > > Key: OAK-4580 > URL: https://issues.apache.org/jira/browse/OAK-4580 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.6, 1.5.11 > > > Oak currently uses version 2.14, which does not support some of the new > features available in 3.2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3574:
Attachment: OAK-3574-lucene-2.patch
New patch with fixed issues. The code processing functions should now be a bit
more encapsulated and easier to re-use (class FunctionIndexProcessor).
Processing now uses a simple stack machine, so it should be easier to extend.
[~chetanm] could you review again please?
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Attachments: OAK-3574-lucene-2.patch, OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3574) Query engine: support p=lowercase('x') and other function-based indexes
[
https://issues.apache.org/jira/browse/OAK-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490514#comment-15490514
]
Thomas Mueller commented on OAK-3574:
-
> this can be computed once
You are right! I will fix that.
> not work if the relative property which is encoded in function gets changed
Good catch! I will add a test case and fix this. I will add the relative
property / properties in collectPropConfigs to the propAggregate list. That
way, a function can potentially have multiple parameters in the future (for
example, a function that calculates the duration based on start and end date).
> Query engine: support p=lowercase('x') and other function-based indexes
> ---
>
> Key: OAK-3574
> URL: https://issues.apache.org/jira/browse/OAK-3574
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Attachments: OAK-3574-lucene.patch
>
>
> Currently, the query engine and indexes don't support function-based indexes
> for conditions of the form lowercase(property) = 'x'. This needs to be
> supported, specially for the Lucene property index.
> Also important is lowercase(name()).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4774) Check usage of DocumentStoreException in MongoDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4774: -- Labels: resilience (was: ) > Check usage of DocumentStoreException in MongoDocumentStore > --- > > Key: OAK-4774 > URL: https://issues.apache.org/jira/browse/OAK-4774 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Labels: resilience > Fix For: 1.6, 1.5.11 > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in MongoDocumentStore and make sure MongoDB Java > driver specific exceptions are handled consistently and wrapped in a > DocumentStoreException. At the same time, cache consistency needs to be > checked as well in case of a driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4774) Check usage of DocumentStoreException in MongoDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4774. --- Resolution: Fixed Fix Version/s: 1.5.11 Added the MongoDocumentStore specific part for the cache consistency test from OAK-4802 and added missing cache invalidation to some of the calls. Fixed in trunk: http://svn.apache.org/r1760709 > Check usage of DocumentStoreException in MongoDocumentStore > --- > > Key: OAK-4774 > URL: https://issues.apache.org/jira/browse/OAK-4774 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.11 > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in MongoDocumentStore and make sure MongoDB Java > driver specific exceptions are handled consistently and wrapped in a > DocumentStoreException. At the same time, cache consistency needs to be > checked as well in case of a driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4802) Basic cache consistency test on exception
[ https://issues.apache.org/jira/browse/OAK-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490374#comment-15490374 ] Marcel Reutegger commented on OAK-4802: --- Extended the test to also check the bulk createOrUpdate() variant: http://svn.apache.org/r1760701 > Basic cache consistency test on exception > - > > Key: OAK-4802 > URL: https://issues.apache.org/jira/browse/OAK-4802 > Project: Jackrabbit Oak > Issue Type: Test > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.11 > > > OAK-4774 and OAK-4793 aim to check if the cache behaviour of a DocumentStore > implementation when the underlying backend throws an exception even though > the operation succeeded. E.g. the response cannot be sent back because of a > network issue. > This issue will provide the DocumentStore independent part of those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4803) Simplify the client side of the cold standby
[
https://issues.apache.org/jira/browse/OAK-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4803:
Attachment: OAK-4803-01.patch
The patch implements everything that is describing in the issue and adds unit
tests for the newly introduced components. Some unnecessary components like
{{StandbyStore}}, {{SegmentLoaderHandler}}, {{StandbyClientHandler}}, and other
encoders and decoders have been removed as part of this patch.
> Simplify the client side of the cold standby
>
>
> Key: OAK-4803
> URL: https://issues.apache.org/jira/browse/OAK-4803
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.12
>
> Attachments: OAK-4803-01.patch
>
>
> The implementation of the cold standby client is overly and unnecessarily
> complicated. It would be way clearer to separate the client code in two major
> components: a simple client responsible for sending messages to and receive
> responses from the standby server, and the synchronization algorithm used to
> read data from the server and to save read data in the local {{FileStore}}.
> Moreover, the client simple client could be further modularised by
> encapsulating request encoding, response decoding and message handling into
> their own Netty handlers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4793) Check usage of DocumentStoreException in RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-4793: -- Attachment: OAK-4793-1.diff Attached diff contains the RDB specific part of the test introduced with OAK-4802. > Check usage of DocumentStoreException in RDBDocumentStore > - > > Key: OAK-4793 > URL: https://issues.apache.org/jira/browse/OAK-4793 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, rdbmk >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4793-1.diff, OAK-4793.diff, OAK-4793.diff > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in RDBDocumentStore and make sure JDBC driver specific > exceptions are handled consistently and wrapped in a DocumentStoreException. > At the same time, cache consistency needs to be checked as well in case of a > driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4802) Basic cache consistency test on exception
[ https://issues.apache.org/jira/browse/OAK-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-4802. --- Resolution: Fixed Fix Version/s: 1.5.11 Added to trunk: http://svn.apache.org/r1760677 > Basic cache consistency test on exception > - > > Key: OAK-4802 > URL: https://issues.apache.org/jira/browse/OAK-4802 > Project: Jackrabbit Oak > Issue Type: Test > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.11 > > > OAK-4774 and OAK-4793 aim to check if the cache behaviour of a DocumentStore > implementation when the underlying backend throws an exception even though > the operation succeeded. E.g. the response cannot be sent back because of a > network issue. > This issue will provide the DocumentStore independent part of those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4803) Simplify the client side of the cold standby
Francesco Mari created OAK-4803:
---
Summary: Simplify the client side of the cold standby
Key: OAK-4803
URL: https://issues.apache.org/jira/browse/OAK-4803
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Reporter: Francesco Mari
Assignee: Francesco Mari
Fix For: Segment Tar 0.0.12
The implementation of the cold standby client is overly and unnecessarily
complicated. It would be way clearer to separate the client code in two major
components: a simple client responsible for sending messages to and receive
responses from the standby server, and the synchronization algorithm used to
read data from the server and to save read data in the local {{FileStore}}.
Moreover, the client simple client could be further modularised by
encapsulating request encoding, response decoding and message handling into
their own Netty handlers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4793) Check usage of DocumentStoreException in RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490225#comment-15490225 ] Marcel Reutegger commented on OAK-4793: --- I will move the test into a separate issue and refactor the test to make it independent of the actual DocumentStore implementation. See OAK-4802. > Check usage of DocumentStoreException in RDBDocumentStore > - > > Key: OAK-4793 > URL: https://issues.apache.org/jira/browse/OAK-4793 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, rdbmk >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4793.diff, OAK-4793.diff > > > With OAK-4771 the usage of DocumentStoreException was clarified in the > DocumentStore interface. The purpose of this task is to check usage of the > DocumentStoreException in RDBDocumentStore and make sure JDBC driver specific > exceptions are handled consistently and wrapped in a DocumentStoreException. > At the same time, cache consistency needs to be checked as well in case of a > driver exception. E.g. invalidate if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4802) Basic cache consistency test on exception
Marcel Reutegger created OAK-4802: - Summary: Basic cache consistency test on exception Key: OAK-4802 URL: https://issues.apache.org/jira/browse/OAK-4802 Project: Jackrabbit Oak Issue Type: Test Components: core, documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.6 OAK-4774 and OAK-4793 aim to check if the cache behaviour of a DocumentStore implementation when the underlying backend throws an exception even though the operation succeeded. E.g. the response cannot be sent back because of a network issue. This issue will provide the DocumentStore independent part of those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4801) Add test for DNS resolution failure in ClientIpFilter
[
https://issues.apache.org/jira/browse/OAK-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4801.
-
Resolution: Fixed
Assignee: Francesco Mari (was: Andrei Dulceanu)
Fix Version/s: (was: Segment Tar 0.0.20)
Segment Tar 0.0.12
Committed with some minor modifications at r1760673.
> Add test for DNS resolution failure in ClientIpFilter
> -
>
> Key: OAK-4801
> URL: https://issues.apache.org/jira/browse/OAK-4801
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: Segment Tar 0.0.12
>
> Attachments: OAK-4801-01.patch
>
>
> Per [~frm]'s suggestion, we could refactor a bit {{ClientIpFilter}} and
> extract the calls to {{InetAddress.getByName()}} into their own interface,
> say {{InetAddressResolver}}. We could then write a test with bogus
> implementation of {{InetAddressResolver}} and assert the behaviour of the
> {{ClientIpFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4712) Publish S3DataStore stats in JMX MBean
[ https://issues.apache.org/jira/browse/OAK-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-4712. Resolution: Fixed Merged into 1.4 branch with http://svn.apache.org/viewvc?rev=1760666=rev > Publish S3DataStore stats in JMX MBean > -- > > Key: OAK-4712 > URL: https://issues.apache.org/jira/browse/OAK-4712 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Matt Ryan >Assignee: Amit Jain > Fix For: 1.4.8, 1.5.11 > > Attachments: OAK-4712.2.diff, OAK-4712.3.diff, OAK-4712.4.diff, > OAK-4712.5.diff, OAK-4712.7.patch, OAK-4712.8.patch, OAK_4712_6_Amit.patch > > > This feature is to publish statistics about the S3DataStore via a JMX MBean. > There are two statistics suggested: > * Indicate the number of files actively being synchronized from the local > cache into S3 > * Given a path to a local file, indicate whether synchronization of file into > S3 has completed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4801) Add test for DNS resolution failure in ClientIpFilter
[
https://issues.apache.org/jira/browse/OAK-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4801:
-
Description: Per [~frm]'s suggestion, we could refactor a bit
{{ClientIpFilter}} and extract the calls to {{InetAddress.getByName()}} into
their own interface, say {{InetAddressResolver}}. We could then write a test
with bogus implementation of {{InetAddressResolver}} and assert the behaviour
of the {{ClientIpFilter}}. (was: Per [~frm]'s suggestion, we could refactor a
bit ClientIpFilter and extract the calls to {{InetAddress.getByName()}} into
their own interface, say {{InetAddressResolver}}. We could then write a test
with bogus implementation of {{InetAddressResolver}} and assert the behaviour
of the {{ClientIpFilter}}.)
> Add test for DNS resolution failure in ClientIpFilter
> -
>
> Key: OAK-4801
> URL: https://issues.apache.org/jira/browse/OAK-4801
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: Segment Tar 0.0.20
>
> Attachments: OAK-4801-01.patch
>
>
> Per [~frm]'s suggestion, we could refactor a bit {{ClientIpFilter}} and
> extract the calls to {{InetAddress.getByName()}} into their own interface,
> say {{InetAddressResolver}}. We could then write a test with bogus
> implementation of {{InetAddressResolver}} and assert the behaviour of the
> {{ClientIpFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4801) Add test for DNS resolution failure in ClientIpFilter
[
https://issues.apache.org/jira/browse/OAK-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4801:
-
Attachment: OAK-4801-01.patch
* Created {{AddressResolver}} and {{InetAddressResolver}} for better testing
{{ClientIPFilter}} without an actual DNS lookup
* Solved hostname with dashes limitation in {{ClientIpFilter}}
* Added {{ClientIPFilterHostnameTest}} for testing filters with hostnames
(including dashes)
[~frm], can you take a look at the patch, please?
/cc [~marett]
> Add test for DNS resolution failure in ClientIpFilter
> -
>
> Key: OAK-4801
> URL: https://issues.apache.org/jira/browse/OAK-4801
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: Segment Tar 0.0.20
>
> Attachments: OAK-4801-01.patch
>
>
> Per [~frm]'s suggestion, we could refactor a bit ClientIpFilter and extract
> the calls to {{InetAddress.getByName()}} into their own interface, say
> {{InetAddressResolver}}. We could then write a test with bogus implementation
> of {{InetAddressResolver}} and assert the behaviour of the {{ClientIpFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4712) Publish S3DataStore stats in JMX MBean
[ https://issues.apache.org/jira/browse/OAK-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-4712: --- Fix Version/s: 1.5.11 1.4.8 > Publish S3DataStore stats in JMX MBean > -- > > Key: OAK-4712 > URL: https://issues.apache.org/jira/browse/OAK-4712 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Matt Ryan >Assignee: Amit Jain > Fix For: 1.4.8, 1.5.11 > > Attachments: OAK-4712.2.diff, OAK-4712.3.diff, OAK-4712.4.diff, > OAK-4712.5.diff, OAK-4712.7.patch, OAK-4712.8.patch, OAK_4712_6_Amit.patch > > > This feature is to publish statistics about the S3DataStore via a JMX MBean. > There are two statistics suggested: > * Indicate the number of files actively being synchronized from the local > cache into S3 > * Given a path to a local file, indicate whether synchronization of file into > S3 has completed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4712) Publish S3DataStore stats in JMX MBean
[ https://issues.apache.org/jira/browse/OAK-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489896#comment-15489896 ] Amit Jain commented on OAK-4712: Thanks a lot [~mattvryan]. I committed the modified version on trunk http://svn.apache.org/viewvc?rev=1760662=rev & http://svn.apache.org/viewvc?rev=1760661=rev The main change is that the the S3DataStoreStats is now a osgi component and the NodeStore, S3DataStore instances are injected. > Publish S3DataStore stats in JMX MBean > -- > > Key: OAK-4712 > URL: https://issues.apache.org/jira/browse/OAK-4712 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Matt Ryan >Assignee: Amit Jain > Fix For: 1.4.8, 1.5.11 > > Attachments: OAK-4712.2.diff, OAK-4712.3.diff, OAK-4712.4.diff, > OAK-4712.5.diff, OAK-4712.7.patch, OAK-4712.8.patch, OAK_4712_6_Amit.patch > > > This feature is to publish statistics about the S3DataStore via a JMX MBean. > There are two statistics suggested: > * Indicate the number of files actively being synchronized from the local > cache into S3 > * Given a path to a local file, indicate whether synchronization of file into > S3 has completed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
