[jira] [Assigned] (OAK-6964) Document tail compaction
[ https://issues.apache.org/jira/browse/OAK-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-6964: -- Assignee: Michael Dürig > Document tail compaction > > > Key: OAK-6964 > URL: https://issues.apache.org/jira/browse/OAK-6964 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: documentation > Fix For: 1.8 > > > We need to add documentation of tail compaction: > * What is it, how does it work? > * How is it configured and scheduled? > * How can it be monitored, what are the related log entries? > * What are its limitations? > * What if it fails? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-7070) rep:excerpt selector broken as regression of OAK-6750
[
https://issues.apache.org/jira/browse/OAK-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294646#comment-16294646
]
Dirk Rudolph commented on OAK-7070:
---
There is still the risk, that duplication appear in the excerpt because there
is a highlighting hit in {{:fulltext}} and one for example in {{full:bar}}. To
prevent that, it probably makes sense to first do the highlighting on
{{:fulltext}} fields when analyzeFulltext is enabled and only if that hasn't
been success full we fallback to the logic of highlighting {{full:}} fields.
wdyt?
> rep:excerpt selector broken as regression of OAK-6750
> -
>
> Key: OAK-7070
> URL: https://issues.apache.org/jira/browse/OAK-7070
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.7, 1.8
>Reporter: Dirk Rudolph
>Assignee: Vikas Saurabh
> Labels: excerpt
>
> The change made here:
> https://github.com/apache/jackrabbit-oak/commit/00c94b71293abcae6d76bb162c3f55c7d09b702e#diff-d4bdf443c61f24b634f33aab607e2114
> breaks the logic in line 676:
> {{else if (oakPropertyName.equals(QueryConstants.REP_EXCERPT + "("))}}
> This statement doesn't make much sense considering a query like {{select
> \[rep:excerpt] from \[test:Page] as page where contains(\*, 'term\*')}} or
> even {{select \[rep:excerpt(text)] from \[test:Page] as page where
> contains(page.\[text], 'term\*')}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-7073) Expose readOnly status for MongoDocumentStore
Chetan Mehrotra created OAK-7073: Summary: Expose readOnly status for MongoDocumentStore Key: OAK-7073 URL: https://issues.apache.org/jira/browse/OAK-7073 Project: Jackrabbit Oak Issue Type: Technical task Components: mongomk Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 1.7.13, 1.8 Provide a way to determine if the MongoDocumentStore is configured for readOnly access -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-7073) Expose readOnly status for MongoDocumentStore
[ https://issues.apache.org/jira/browse/OAK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-7073. -- Resolution: Fixed Done with 1818533 > Expose readOnly status for MongoDocumentStore > - > > Key: OAK-7073 > URL: https://issues.apache.org/jira/browse/OAK-7073 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.7.13, 1.8 > > > Provide a way to determine if the MongoDocumentStore is configured for > readOnly access -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294720#comment-16294720
]
Hudson commented on OAK-7054:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1100|https://builds.apache.org/job/Jackrabbit%20Oak/1100/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1100/console]
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-7066) Active deletion blob list files can grow too large due to inlined blobs
[
https://issues.apache.org/jira/browse/OAK-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7066:
---
Fix Version/s: 1.7.13
1.8.
> Active deletion blob list files can grow too large due to inlined blobs
> ---
>
> Key: OAK-7066
> URL: https://issues.apache.org/jira/browse/OAK-7066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.7.13, 1.8.
>
>
> This is follow up from OAK-7052 where we noticed that deleted blob list files
> collected by active deletion logic can grow very large due to inlined blobs.
> One potential way (not sure how yet though) is to not actively delete inlined
> blobs.
> Here are some stats which might help us take a call (based on raw numbers
> collected at \[0])
> ||file-name||large_lines||large_size||small_lines||small_size||small_lines/total_lines||small_size/total_size||
> |blobs-1512664032264.txt|245301|3310224358|173096|35473656|0.413712335413495|0.010602766852107|
> |blobs-1512698405656.txt|370373|4443957885|256775|52997864|0.409432861142824|0.011785275852845|
> |blobs-1512987450004.txt|660669|6214740439|461168|92017554|0.411082893504137|0.014590309966251|
> |blobs-1513130410963.txt|569083|5490965583|406756|80124598|0.416826956085994|0.014382211631264|
> |blobs-1513216819447.txt|69876|1413561892|46238|9221956|0.398212101899857|0.006481628262061|
> \[0]:
> file sizes
> {noformat}
> repository/index/deleted-blobs$ ls -l blobs-151*
> -rw-r--r-- 1 root root 3369065620 Dec 8 01:59 blobs-1512664032264.txt
> -rw-r--r-- 1 root root 4532250073 Dec 9 01:59 blobs-1512698405656.txt
> -rw-r--r-- 1 root root 6370201955 Dec 13 01:59 blobs-1512987450004.txt
> -rw-r--r-- 1 root root 1916223582 Dec 13 11:52 blobs-1513130410963.txt
> {noformat}
> number of entries
> {noformat}
> repository/index/deleted-blobs$ wc -l blobs-151*
> 418397 blobs-1512664032264.txt
> 627148 blobs-1512698405656.txt
> 1121837 blobs-1512987450004.txt
> 308292 blobs-1513130410963.txt
> 2475674 total
> {noformat}
> number of entries and sizes split on threshold of 500 bytes of blob ids
> {noformat}
> repository/index/deleted-blobs$ for i in blobs-151*;do echo $i;awk 'BEGIN
> {FS="|"} {len = length($1); if (len > 500) {large++; largeSize+=len} else
> {small++; smallSize+=len}} END {print large, largeSize, small, smallSize}'
> $i;done
> blobs-1512664032264.txt
> 245301 3310224358 173096 35473656
> blobs-1512698405656.txt
> 370373 4443957885 256775 52997864
> blobs-1512987450004.txt
> 660669 6214740439 461168 92017554
> blobs-1513130410963.txt
> 569083 5490965583 406756 80124598
> blobs-1513216819447.txt
> 69876 1413561892 46238 9221956
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-7066) Active deletion blob list files can grow too large due to inlined blobs
[
https://issues.apache.org/jira/browse/OAK-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7066:
---
Priority: Blocker (was: Major)
> Active deletion blob list files can grow too large due to inlined blobs
> ---
>
> Key: OAK-7066
> URL: https://issues.apache.org/jira/browse/OAK-7066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Fix For: 1.7.13, 1.8.
>
>
> This is follow up from OAK-7052 where we noticed that deleted blob list files
> collected by active deletion logic can grow very large due to inlined blobs.
> One potential way (not sure how yet though) is to not actively delete inlined
> blobs.
> Here are some stats which might help us take a call (based on raw numbers
> collected at \[0])
> ||file-name||large_lines||large_size||small_lines||small_size||small_lines/total_lines||small_size/total_size||
> |blobs-1512664032264.txt|245301|3310224358|173096|35473656|0.413712335413495|0.010602766852107|
> |blobs-1512698405656.txt|370373|4443957885|256775|52997864|0.409432861142824|0.011785275852845|
> |blobs-1512987450004.txt|660669|6214740439|461168|92017554|0.411082893504137|0.014590309966251|
> |blobs-1513130410963.txt|569083|5490965583|406756|80124598|0.416826956085994|0.014382211631264|
> |blobs-1513216819447.txt|69876|1413561892|46238|9221956|0.398212101899857|0.006481628262061|
> \[0]:
> file sizes
> {noformat}
> repository/index/deleted-blobs$ ls -l blobs-151*
> -rw-r--r-- 1 root root 3369065620 Dec 8 01:59 blobs-1512664032264.txt
> -rw-r--r-- 1 root root 4532250073 Dec 9 01:59 blobs-1512698405656.txt
> -rw-r--r-- 1 root root 6370201955 Dec 13 01:59 blobs-1512987450004.txt
> -rw-r--r-- 1 root root 1916223582 Dec 13 11:52 blobs-1513130410963.txt
> {noformat}
> number of entries
> {noformat}
> repository/index/deleted-blobs$ wc -l blobs-151*
> 418397 blobs-1512664032264.txt
> 627148 blobs-1512698405656.txt
> 1121837 blobs-1512987450004.txt
> 308292 blobs-1513130410963.txt
> 2475674 total
> {noformat}
> number of entries and sizes split on threshold of 500 bytes of blob ids
> {noformat}
> repository/index/deleted-blobs$ for i in blobs-151*;do echo $i;awk 'BEGIN
> {FS="|"} {len = length($1); if (len > 500) {large++; largeSize+=len} else
> {small++; smallSize+=len}} END {print large, largeSize, small, smallSize}'
> $i;done
> blobs-1512664032264.txt
> 245301 3310224358 173096 35473656
> blobs-1512698405656.txt
> 370373 4443957885 256775 52997864
> blobs-1512987450004.txt
> 660669 6214740439 461168 92017554
> blobs-1513130410963.txt
> 569083 5490965583 406756 80124598
> blobs-1513216819447.txt
> 69876 1413561892 46238 9221956
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6353) Use Document order traversal for reindexing performed on DocumentNodeStore setups
[ https://issues.apache.org/jira/browse/OAK-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294747#comment-16294747 ] Chetan Mehrotra commented on OAK-6353: -- There are some aspects which still need to be taken care of. See OAK-7074 > Use Document order traversal for reindexing performed on DocumentNodeStore > setups > - > > Key: OAK-6353 > URL: https://issues.apache.org/jira/browse/OAK-6353 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.7.13, 1.8 > > Attachments: OAK-6353-v1.patch, OAK-6353-v2.patch > > > [~tmueller] suggested > [here|https://issues.apache.org/jira/browse/OAK-6246?focusedCommentId=16034442&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16034442] > that document order traversal can be faster compared to current mode of path > based traversal. Initial test indicate that such a traversal can be order of > magnitude faster. > So this task is meant to implement such an approach and see if it can be a > viable indexing mode used for DocumentNodeStore based setups -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-7074) Ensure that all Documents are read with document order traversal indexing
Chetan Mehrotra created OAK-7074: Summary: Ensure that all Documents are read with document order traversal indexing Key: OAK-7074 URL: https://issues.apache.org/jira/browse/OAK-7074 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk, run Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.8 With OAK-6353 support was added for document order traversal indexing. In this mode we open a DB cursor and try to read all documents from it using document order traversal. Such a cursor may remain open for long time (2-4 hrs) and its possible that document may get reordered by the Mongo storage engine. This would result in 2 aspects to be thought about # Duplicate documents - Same document may appear more than once in result set # Possibly missed document - It may be a possibility that a document got moved and missed becoming part of cursor. Both these aspects would need to be handled -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-7066) Active deletion blob list files can grow too large due to inlined blobs
[
https://issues.apache.org/jira/browse/OAK-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-7066.
Resolution: Fixed
Fixed in trunk at [r1818545|https://svn.apache.org/r1818545].
> Active deletion blob list files can grow too large due to inlined blobs
> ---
>
> Key: OAK-7066
> URL: https://issues.apache.org/jira/browse/OAK-7066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Fix For: 1.7.13, 1.8.
>
>
> This is follow up from OAK-7052 where we noticed that deleted blob list files
> collected by active deletion logic can grow very large due to inlined blobs.
> One potential way (not sure how yet though) is to not actively delete inlined
> blobs.
> Here are some stats which might help us take a call (based on raw numbers
> collected at \[0])
> ||file-name||large_lines||large_size||small_lines||small_size||small_lines/total_lines||small_size/total_size||
> |blobs-1512664032264.txt|245301|3310224358|173096|35473656|0.413712335413495|0.010602766852107|
> |blobs-1512698405656.txt|370373|4443957885|256775|52997864|0.409432861142824|0.011785275852845|
> |blobs-1512987450004.txt|660669|6214740439|461168|92017554|0.411082893504137|0.014590309966251|
> |blobs-1513130410963.txt|569083|5490965583|406756|80124598|0.416826956085994|0.014382211631264|
> |blobs-1513216819447.txt|69876|1413561892|46238|9221956|0.398212101899857|0.006481628262061|
> \[0]:
> file sizes
> {noformat}
> repository/index/deleted-blobs$ ls -l blobs-151*
> -rw-r--r-- 1 root root 3369065620 Dec 8 01:59 blobs-1512664032264.txt
> -rw-r--r-- 1 root root 4532250073 Dec 9 01:59 blobs-1512698405656.txt
> -rw-r--r-- 1 root root 6370201955 Dec 13 01:59 blobs-1512987450004.txt
> -rw-r--r-- 1 root root 1916223582 Dec 13 11:52 blobs-1513130410963.txt
> {noformat}
> number of entries
> {noformat}
> repository/index/deleted-blobs$ wc -l blobs-151*
> 418397 blobs-1512664032264.txt
> 627148 blobs-1512698405656.txt
> 1121837 blobs-1512987450004.txt
> 308292 blobs-1513130410963.txt
> 2475674 total
> {noformat}
> number of entries and sizes split on threshold of 500 bytes of blob ids
> {noformat}
> repository/index/deleted-blobs$ for i in blobs-151*;do echo $i;awk 'BEGIN
> {FS="|"} {len = length($1); if (len > 500) {large++; largeSize+=len} else
> {small++; smallSize+=len}} END {print large, largeSize, small, smallSize}'
> $i;done
> blobs-1512664032264.txt
> 245301 3310224358 173096 35473656
> blobs-1512698405656.txt
> 370373 4443957885 256775 52997864
> blobs-1512987450004.txt
> 660669 6214740439 461168 92017554
> blobs-1513130410963.txt
> 569083 5490965583 406756 80124598
> blobs-1513216819447.txt
> 69876 1413561892 46238 9221956
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-7066) Active deletion blob list files can grow too large due to inlined blobs
[
https://issues.apache.org/jira/browse/OAK-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294750#comment-16294750
]
Vikas Saurabh edited comment on OAK-7066 at 12/18/17 10:23 AM:
---
Fixed in trunk at [r1818545|https://svn.apache.org/r1818545].
FTR: I've used {{InMemoryDataRecord#isInstance}} - thus inlined binaries for
data store won't make into recorded blob ids for active deletion. Otoh, blob
store ones would always make it there.
was (Author: catholicon):
Fixed in trunk at [r1818545|https://svn.apache.org/r1818545].
> Active deletion blob list files can grow too large due to inlined blobs
> ---
>
> Key: OAK-7066
> URL: https://issues.apache.org/jira/browse/OAK-7066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Fix For: 1.7.13, 1.8.
>
>
> This is follow up from OAK-7052 where we noticed that deleted blob list files
> collected by active deletion logic can grow very large due to inlined blobs.
> One potential way (not sure how yet though) is to not actively delete inlined
> blobs.
> Here are some stats which might help us take a call (based on raw numbers
> collected at \[0])
> ||file-name||large_lines||large_size||small_lines||small_size||small_lines/total_lines||small_size/total_size||
> |blobs-1512664032264.txt|245301|3310224358|173096|35473656|0.413712335413495|0.010602766852107|
> |blobs-1512698405656.txt|370373|4443957885|256775|52997864|0.409432861142824|0.011785275852845|
> |blobs-1512987450004.txt|660669|6214740439|461168|92017554|0.411082893504137|0.014590309966251|
> |blobs-1513130410963.txt|569083|5490965583|406756|80124598|0.416826956085994|0.014382211631264|
> |blobs-1513216819447.txt|69876|1413561892|46238|9221956|0.398212101899857|0.006481628262061|
> \[0]:
> file sizes
> {noformat}
> repository/index/deleted-blobs$ ls -l blobs-151*
> -rw-r--r-- 1 root root 3369065620 Dec 8 01:59 blobs-1512664032264.txt
> -rw-r--r-- 1 root root 4532250073 Dec 9 01:59 blobs-1512698405656.txt
> -rw-r--r-- 1 root root 6370201955 Dec 13 01:59 blobs-1512987450004.txt
> -rw-r--r-- 1 root root 1916223582 Dec 13 11:52 blobs-1513130410963.txt
> {noformat}
> number of entries
> {noformat}
> repository/index/deleted-blobs$ wc -l blobs-151*
> 418397 blobs-1512664032264.txt
> 627148 blobs-1512698405656.txt
> 1121837 blobs-1512987450004.txt
> 308292 blobs-1513130410963.txt
> 2475674 total
> {noformat}
> number of entries and sizes split on threshold of 500 bytes of blob ids
> {noformat}
> repository/index/deleted-blobs$ for i in blobs-151*;do echo $i;awk 'BEGIN
> {FS="|"} {len = length($1); if (len > 500) {large++; largeSize+=len} else
> {small++; smallSize+=len}} END {print large, largeSize, small, smallSize}'
> $i;done
> blobs-1512664032264.txt
> 245301 3310224358 173096 35473656
> blobs-1512698405656.txt
> 370373 4443957885 256775 52997864
> blobs-1512987450004.txt
> 660669 6214740439 461168 92017554
> blobs-1513130410963.txt
> 569083 5490965583 406756 80124598
> blobs-1513216819447.txt
> 69876 1413561892 46238 9221956
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-3855) oak-run compact should check segment version
[
https://issues.apache.org/jira/browse/OAK-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294770#comment-16294770
]
Valentin Olteanu commented on OAK-3855:
---
[~mduerig], is the new parameter already documented somewhere?
> oak-run compact should check segment version
>
>
> Key: OAK-3855
> URL: https://issues.apache.org/jira/browse/OAK-3855
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: gc, resilience, tooling
> Fix For: 1.3.15, 1.4
>
>
> Off line compaction should exit with a warning if run on a store with non
> matching segment version. It should provide a {{--force}} option to override
> this behaviour such that it can still be used for explicit upgrading.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6625) Avoid oak-run compact inadvertently upgrading the segment format
[
https://issues.apache.org/jira/browse/OAK-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294784#comment-16294784
]
Michael Dürig commented on OAK-6625:
Re.
https://issues.apache.org/jira/browse/OAK-3855?focusedCommentId=16294770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16294770:
No {{-force}} is not yet mentioned in {{oak-docs}}. I'll fix this.
> Avoid oak-run compact inadvertently upgrading the segment format
> -
>
> Key: OAK-6625
> URL: https://issues.apache.org/jira/browse/OAK-6625
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: gc, production, resilience
> Fix For: 1.7.7, 1.8
>
>
> The transparent upgrade feature for segments from version 12 to 13 should not
> cause "accidental upgrades". That is, running Oak 1.8 oak-run compact on a
> store with segment version 12 should bail out unless a special option was
> specified on the command line.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-3855) oak-run compact should check segment version
[
https://issues.apache.org/jira/browse/OAK-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294782#comment-16294782
]
Michael Dürig commented on OAK-3855:
[~volteanu], I'll follow up on, where your comment applies for Oak 1.8.
> oak-run compact should check segment version
>
>
> Key: OAK-3855
> URL: https://issues.apache.org/jira/browse/OAK-3855
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: gc, resilience, tooling
> Fix For: 1.3.15, 1.4
>
>
> Off line compaction should exit with a warning if run on a store with non
> matching segment version. It should provide a {{--force}} option to override
> this behaviour such that it can still be used for explicit upgrading.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6625) Avoid oak-run compact inadvertently upgrading the segment format
[
https://issues.apache.org/jira/browse/OAK-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294784#comment-16294784
]
Michael Dürig edited comment on OAK-6625 at 12/18/17 10:44 AM:
---
Re.
https://issues.apache.org/jira/browse/OAK-3855?focusedCommentId=16294770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16294770:
No {{-force}} is not yet mentioned in {{oak-doc}}. I'll fix this.
was (Author: mduerig):
Re.
https://issues.apache.org/jira/browse/OAK-3855?focusedCommentId=16294770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16294770:
No {{-force}} is not yet mentioned in {{oak-docs}}. I'll fix this.
> Avoid oak-run compact inadvertently upgrading the segment format
> -
>
> Key: OAK-6625
> URL: https://issues.apache.org/jira/browse/OAK-6625
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: gc, production, resilience
> Fix For: 1.7.7, 1.8
>
>
> The transparent upgrade feature for segments from version 12 to 13 should not
> cause "accidental upgrades". That is, running Oak 1.8 oak-run compact on a
> store with segment version 12 should bail out unless a special option was
> specified on the command line.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6625) Avoid oak-run compact inadvertently upgrading the segment format
[
https://issues.apache.org/jira/browse/OAK-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294784#comment-16294784
]
Michael Dürig edited comment on OAK-6625 at 12/18/17 10:47 AM:
---
Re.
https://issues.apache.org/jira/browse/OAK-3855?focusedCommentId=16294770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16294770:
No {{-force}} is not yet mentioned in {{oak-doc}}. I'll fix this.
See OAK-7075.
was (Author: mduerig):
Re.
https://issues.apache.org/jira/browse/OAK-3855?focusedCommentId=16294770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16294770:
No {{-force}} is not yet mentioned in {{oak-doc}}. I'll fix this.
> Avoid oak-run compact inadvertently upgrading the segment format
> -
>
> Key: OAK-6625
> URL: https://issues.apache.org/jira/browse/OAK-6625
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: gc, production, resilience
> Fix For: 1.7.7, 1.8
>
>
> The transparent upgrade feature for segments from version 12 to 13 should not
> cause "accidental upgrades". That is, running Oak 1.8 oak-run compact on a
> store with segment version 12 should bail out unless a special option was
> specified on the command line.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-7075) Document oak-run compact arguments and system properties
[
https://issues.apache.org/jira/browse/OAK-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-7075:
--
Assignee: Michael Dürig
> Document oak-run compact arguments and system properties
>
>
> Key: OAK-7075
> URL: https://issues.apache.org/jira/browse/OAK-7075
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: documentation
> Fix For: 1.8
>
>
> Ensure {{oak-doc}} is up to date with the current version of {{oak-run
> compact}}, its current command line arguments and system properties.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-7075) Document oak-run compact arguments and system properties
Michael Dürig created OAK-7075:
--
Summary: Document oak-run compact arguments and system properties
Key: OAK-7075
URL: https://issues.apache.org/jira/browse/OAK-7075
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-tar
Reporter: Michael Dürig
Fix For: 1.8
Ensure {{oak-doc}} is up to date with the current version of {{oak-run
compact}}, its current command line arguments and system properties.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-7076) Update Oak 1.0 to Jackrabbit 2.8.7
Julian Reschke created OAK-7076: --- Summary: Update Oak 1.0 to Jackrabbit 2.8.7 Key: OAK-7076 URL: https://issues.apache.org/jira/browse/OAK-7076 Project: Jackrabbit Oak Issue Type: Task Components: parent Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.0.40 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294799#comment-16294799
]
Hudson commented on OAK-7054:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1101|https://builds.apache.org/job/Jackrabbit%20Oak/1101/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1101/console]
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294810#comment-16294810
]
Tommaso Teofili commented on OAK-7054:
--
I think the core problem is what Marcel found out, the OOM problem is a
consequence of the repeated failing initializations of Solr cores.
Even in the latest build failure
[unit-test.log|https://builds.apache.org/job/Jackrabbit%20Oak/1099/artifact/oak-solr-core/target/unit-tests.log]
the core is started with options which do not reflect the recent changes in
solrconfig.xml.
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-7077) Document RDBDocumentStore statistics
Julian Reschke created OAK-7077: --- Summary: Document RDBDocumentStore statistics Key: OAK-7077 URL: https://issues.apache.org/jira/browse/OAK-7077 Project: Jackrabbit Oak Issue Type: Task Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294866#comment-16294866
]
Tommaso Teofili commented on OAK-7054:
--
the problem stands in the fact that the {{EmbeddedSolrServer}} started within
{{SolrOakRepositoryStub}} comes from the very same location in every build
(since ages, I now realise) because of the suboptimal path initialization below
{code}
String path = getClass().getResource("/").getFile() + "/queryjcrtest"
{code}
It should be replaced with something that guarantees that the above path goes
under a randomized directory name under _target_ every time.
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294870#comment-16294870
]
Tommaso Teofili commented on OAK-7054:
--
I've committed a fix (r1818554) that should make the build green again.
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294885#comment-16294885
]
Hudson commented on OAK-7054:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1102|https://builds.apache.org/job/Jackrabbit%20Oak/1102/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1102/console]
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6737) Standby server should send timely responses to all client requests
[
https://issues.apache.org/jira/browse/OAK-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-6737:
-
Fix Version/s: (was: 1.7.13)
> Standby server should send timely responses to all client requests
> --
>
> Key: OAK-6737
> URL: https://issues.apache.org/jira/browse/OAK-6737
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, tarmk-standby
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.8
>
>
> Currently all the {{GetXXXRequestHandler}} (where XXX stands for Blob, Head,
> References and Segment), on the server discard client requests which cannot
> be satisfied (i.e. the requested object does not exist (yet) on the server).
> A more transparent approach would be to timely respond to all client
> requests, clearly stating that the object was not found. This would improve a
> lot debugging for example, because all requests and their responses could be
> easily followed from the client log, without needing to know what actually
> happened on the server.
> Below, a possible implementation for {{GetHeadRequestHandler}}, suggested by
> [~frm] in a comment on OAK-6678:
> {noformat}
> String id = reader.readHeadRecordId();
> if (id == null) {
> ctx.writeAndFlush(new NotFoundGetHeadResponse(msg.getClientId(), id));
> return;
> }
> ctx.writeAndFlush(new GetHeadResponse(msg.getClientId(), id));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294941#comment-16294941
]
Tommaso Teofili commented on OAK-7054:
--
https://builds.apache.org/job/Jackrabbit%20Oak/1103/ should be green.
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294944#comment-16294944
]
Hudson commented on OAK-7054:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1103|https://builds.apache.org/job/Jackrabbit%20Oak/1103/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1103/console]
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.8
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (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 resolved OAK-4318. -- Resolution: Fixed Fix Version/s: (was: 1.8) > 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.7.13 > > Attachments: OAK-4318.1.patch, 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.4.14#64029)
[jira] [Resolved] (OAK-7054) Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
[
https://issues.apache.org/jira/browse/OAK-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-7054.
--
Resolution: Fixed
Fix Version/s: (was: 1.8)
1.7.13
> Build failure: ClassNotFoundException: solr.JsonUpdateRequestHandler
>
>
> Key: OAK-7054
> URL: https://issues.apache.org/jira/browse/OAK-7054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Assignee: Tommaso Teofili
> Fix For: 1.7.13
>
>
> No description is provided
> The build Jackrabbit Oak #1075 has failed.
> First failed run: [Jackrabbit Oak
> #1075|https://builds.apache.org/job/Jackrabbit%20Oak/1075/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1075/console]
> {noformat}
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.723
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest
> [ERROR]
> testIgnoredPropertiesNotIndexed(org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest)
> Time elapsed: 0.475 s <<< ERROR!
> java.lang.RuntimeException: org.apache.solr.common.SolrException: SolrCore
> 'oak' is not available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: SolrCore 'oak' is not
> available due to init failure: Error loading class
> 'solr.JsonUpdateRequestHandler'
> at
> org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest.testIgnoredPropertiesNotIndexed(SolrIndexEditorTest.java:71)
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: org.apache.solr.common.SolrException: Error loading class
> 'solr.JsonUpdateRequestHandler'
> Caused by: java.lang.ClassNotFoundException: solr.JsonUpdateRequestHandler
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6606) Move BulkTransferBenchmark to oak-benchmarks module
[
https://issues.apache.org/jira/browse/OAK-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6606:
--
Fix Version/s: (was: 1.7.13)
> Move BulkTransferBenchmark to oak-benchmarks module
> ---
>
> Key: OAK-6606
> URL: https://issues.apache.org/jira/browse/OAK-6606
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: cold-standby
> Fix For: 1.8
>
>
> {{BulkTransferBenchmark}} should be moved from {{oak-segment-tar}} to
> {{oak-benchmarks}} to allow standard run of this cold standby related
> benchmark.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6674) Create a more complex IT for cold standby
[
https://issues.apache.org/jira/browse/OAK-6674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6674:
--
Fix Version/s: (was: 1.7.13)
> Create a more complex IT for cold standby
> -
>
> Key: OAK-6674
> URL: https://issues.apache.org/jira/browse/OAK-6674
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar, tarmk-standby
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
> Labels: cold-standby
> Fix For: 1.8
>
>
> At the moment all integration tests for cold standby are using the same
> scenario in their tests: some content is created on the server (including
> binaries), a standby sync cycle is started and then the content is checked on
> the client. The only twist here is using/not using a data store for storing
> binaries.
> Although good, this model could be extended to cover many more cases. For
> example, {{StandbyDiff}} covers the following 6 cases node/property
> added/changed/deleted. From these, with the scenario described, the removal
> part is never tested (and the change part is covered in only one test).
> It would be nice to have an IT which would add content on the server, do a
> sync, remove some of the content, do a sync and then call OnRC. This way all
> cases will be covered, including if cleanup works as expected on the client.
> /cc [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-5877) Oak upgrade usage note refers to oak-run
[
https://issues.apache.org/jira/browse/OAK-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-5877:
--
Fix Version/s: (was: 1.7.13)
> Oak upgrade usage note refers to oak-run
>
>
> Key: OAK-5877
> URL: https://issues.apache.org/jira/browse/OAK-5877
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Reporter: Michael Dürig
>Priority: Minor
> Labels: production, tooling, usability
> Fix For: 1.8
>
>
> Running {{java -jar oak-upgrade*.jar}} prints
> {noformat}
> Usage: java -jar oak-run-*-jr2.jar upgrade [options] jcr2_source [destination]
>(to upgrade a JCR 2 repository)
>java -jar oak-run-*-jr2.jar upgrade [options] source destination
>(to migrate an Oak repository)
> {noformat}
> Which incorrectly refers to {{oak-run upgrade}}. The latter will send me back
> to {{oak-run}}: "This command was moved to the oak-upgrade module".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OAK-5885) segment-tar should have a tarmkrecovery command
[
https://issues.apache.org/jira/browse/OAK-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-5885:
Assignee: (was: Andrei Dulceanu)
> segment-tar should have a tarmkrecovery command
> ---
>
> Key: OAK-5885
> URL: https://issues.apache.org/jira/browse/OAK-5885
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Priority: Minor
> Labels: tooling
> Fix For: 1.8
>
>
> {{oak-segment}} had a {{tarmkrecovery}} command responsible with listing
> candidates for head journal entries. We should re-enable this also for
> {{oak-segment-tar}}.
> /cc [~mduerig] [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-7078) NullPointerException in FilteredSortedSetDocValuesFacetCounts during query evaluation
Dirk Rudolph created OAK-7078:
-
Summary: NullPointerException in
FilteredSortedSetDocValuesFacetCounts during query evaluation
Key: OAK-7078
URL: https://issues.apache.org/jira/browse/OAK-7078
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Affects Versions: 1.6.7
Reporter: Dirk Rudolph
Running the following query {{select \[rep:facet(simple/tags)] from \[nt:base]
where contains(\[text], 'ipsum')}} with the following content
{code}
/content/foo
- text = "lorem lorem"
+ simple/
- tags = ["tag1", "tag2"]
/content/bar
- text = "lorem
{code}
runs in the following NPE
{code}
java.lang.NullPointerException
at
org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
at
org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
... 38 more
{code}
This is because the result set for the query only contains {{/content/bar}} and
with that the count of the dimension {{simple/tag}} is 0. For that case
[SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
returns {{null}} and so does {{getTopChildren}}.
This expected behaviour is properly handled in
[LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
but not in
[FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
where {{topChildren}} is dereferenced without null check.
To workaround that secure facets can be set to false, though the default value
is true.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-7078) NullPointerException in FilteredSortedSetDocValuesFacetCounts during query evaluation
[
https://issues.apache.org/jira/browse/OAK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295793#comment-16295793
]
Dirk Rudolph commented on OAK-7078:
---
I created [#77|https://github.com/apache/jackrabbit-oak/pull/77] which contains
a unit test and the necessary null check for derlerencing topChildren in
FilteredSortedSetDocValuesFacetCounts.
> NullPointerException in FilteredSortedSetDocValuesFacetCounts during query
> evaluation
> -
>
> Key: OAK-7078
> URL: https://issues.apache.org/jira/browse/OAK-7078
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.7
>Reporter: Dirk Rudolph
>
> Running the following query {{select \[rep:facet(simple/tags)] from
> \[nt:base] where contains(\[text], 'ipsum')}} with the following content
> {code}
> /content/foo
> - text = "lorem lorem"
> + simple/
>- tags = ["tag1", "tag2"]
> /content/bar
> - text = "lorem
> {code}
> runs in the following NPE
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
> at
> org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
> ... 38 more
> {code}
> This is because the result set for the query only contains {{/content/bar}}
> and with that the count of the dimension {{simple/tag}} is 0. For that case
> [SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
> returns {{null}} and so does {{getTopChildren}}.
> This expected behaviour is properly handled in
> [LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
> but not in
> [FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
> where {{topChildren}} is dereferenced without null check.
> To workaround that secure facets can be set to false, though the default
> value is true.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-7078) NullPointerException in FilteredSortedSetDocValuesFacetCounts during query evaluation
[
https://issues.apache.org/jira/browse/OAK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295793#comment-16295793
]
Dirk Rudolph edited comment on OAK-7078 at 12/18/17 10:52 PM:
--
I created [#77|https://github.com/apache/jackrabbit-oak/pull/77] which contains
a unit test and the necessary null check for derlerencing topChildren in
FilteredSortedSetDocValuesFacetCounts.
In case thats ok, I would like to ask for backporting that to 1.6 branch at
least (for backwards compatibility in AEM 6.3)
was (Author: diru):
I created [#77|https://github.com/apache/jackrabbit-oak/pull/77] which contains
a unit test and the necessary null check for derlerencing topChildren in
FilteredSortedSetDocValuesFacetCounts.
> NullPointerException in FilteredSortedSetDocValuesFacetCounts during query
> evaluation
> -
>
> Key: OAK-7078
> URL: https://issues.apache.org/jira/browse/OAK-7078
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.7
>Reporter: Dirk Rudolph
>
> Running the following query {{select \[rep:facet(simple/tags)] from
> \[nt:base] where contains(\[text], 'ipsum')}} with the following content
> {code}
> /content/foo
> - text = "lorem lorem"
> + simple/
>- tags = ["tag1", "tag2"]
> /content/bar
> - text = "lorem
> {code}
> runs in the following NPE
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
> at
> org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
> ... 38 more
> {code}
> This is because the result set for the query only contains {{/content/bar}}
> and with that the count of the dimension {{simple/tag}} is 0. For that case
> [SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
> returns {{null}} and so does {{getTopChildren}}.
> This expected behaviour is properly handled in
> [LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
> but not in
> [FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
> where {{topChildren}} is dereferenced without null check.
> To workaround that secure facets can be set to false, though the default
> value is true.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-7078) NullPointerException in FilteredSortedSetDocValuesFacetCounts during query evaluation
[
https://issues.apache.org/jira/browse/OAK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated OAK-7078:
--
Labels: facet (was: )
> NullPointerException in FilteredSortedSetDocValuesFacetCounts during query
> evaluation
> -
>
> Key: OAK-7078
> URL: https://issues.apache.org/jira/browse/OAK-7078
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.7
>Reporter: Dirk Rudolph
> Labels: facet
>
> Running the following query {{select \[rep:facet(simple/tags)] from
> \[nt:base] where contains(\[text], 'ipsum')}} with the following content
> {code}
> /content/foo
> - text = "lorem lorem"
> + simple/
>- tags = ["tag1", "tag2"]
> /content/bar
> - text = "lorem
> {code}
> runs in the following NPE
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
> at
> org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
> ... 38 more
> {code}
> This is because the result set for the query only contains {{/content/bar}}
> and with that the count of the dimension {{simple/tag}} is 0. For that case
> [SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
> returns {{null}} and so does {{getTopChildren}}.
> This expected behaviour is properly handled in
> [LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
> but not in
> [FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
> where {{topChildren}} is dereferenced without null check.
> To workaround that secure facets can be set to false, though the default
> value is true.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-7078) NullPointerException in FilteredSortedSetDocValuesFacetCounts during query evaluation
[
https://issues.apache.org/jira/browse/OAK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated OAK-7078:
--
Description:
Running the following query {{select \[rep:facet(simple/tags)] from \[nt:base]
where contains(\[text], 'ipsum')}} with the following content
{code}
/content/foo
- text = "lorem lorem"
+ simple/
- tags = ["tag1", "tag2"]
/content/bar
- text = "lorem ipsum"
{code}
runs in the following NPE
{code}
java.lang.NullPointerException
at
org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
at
org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
... 38 more
{code}
This is because the result set for the query only contains {{/content/bar}} and
with that the count of the dimension {{simple/tag}} is 0. For that case
[SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
returns {{null}} and so does {{getTopChildren}}.
This expected behaviour is properly handled in
[LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
but not in
[FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
where {{topChildren}} is dereferenced without null check.
To workaround that secure facets can be set to false, though the default value
is true.
was:
Running the following query {{select \[rep:facet(simple/tags)] from \[nt:base]
where contains(\[text], 'ipsum')}} with the following content
{code}
/content/foo
- text = "lorem lorem"
+ simple/
- tags = ["tag1", "tag2"]
/content/bar
- text = "lorem
{code}
runs in the following NPE
{code}
java.lang.NullPointerException
at
org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
at
org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$2.getValue(LucenePropertyIndex.java:1646)
... 38 more
{code}
This is because the result set for the query only contains {{/content/bar}} and
with that the count of the dimension {{simple/tag}} is 0. For that case
[SortedSetDocValuesFacetCounts#getDim()|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.7.1/lucene/facet/src/java/org/apache/lucene/facet/sortedset/SortedSetDocValuesFacetCounts.java#L108]
returns {{null}} and so does {{getTopChildren}}.
This expected behaviour is properly handled in
[LucenePropertyIndex.java#L1647|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1647]
but not in
[FilteredSortedSetDocValuesFacetCounts.java#L63|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/FilteredSortedSetDocValuesFacetCounts.java#L63]
where {{topChildren}} is dereferenced without null check.
To workaround that secure facets can be set to false, though the default value
is true.
> NullPointerException in FilteredSortedSetDocValuesFacetCounts during query
> evaluation
> -
>
> Key: OAK-7078
> URL: https://issues.apache.org/jira/browse/OAK-7078
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.6.7
>Reporter: Dirk Rudolph
> Labels: facet
>
> Running the following query {{select \[rep:facet(simple/tags)] from
> \[nt:base] where contains(\[text], 'ipsum')}} with the following content
> {code}
> /content/foo
> - text = "lorem lorem"
> + simple/
>- tags = ["tag1", "tag2"]
> /content/bar
> - text = "lorem ipsum"
> {code}
> runs in the following NPE
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.FilteredSortedSetDocValuesFacetCounts.getTopChildren(FilteredSortedSetDocValuesFacetCounts.java:63)
> at
> org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.Luc
[jira] [Commented] (OAK-7074) Ensure that all Documents are read with document order traversal indexing
[ https://issues.apache.org/jira/browse/OAK-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16296232#comment-16296232 ] Chetan Mehrotra commented on OAK-7074: -- With 1818634 now sorting uses distinct mode to avoid duplicates. [~catholicon] mentioned in offline discussion that for duplicates we just need to ensure NodeStateEntries are unique per per. It does not matter for same path which entry is picked. Further document may appear more than once in a cursor traversal for one of the following cases # Document was updated - If document gets updated then it may be moved around and thus may appear twice in natural order traversal. So while sorting we can still pick anyone as the NodeState view for the checkpoint revision would be same for both Mongo documents. # Document was moved due to internal design of Mongo - It may happen that Mongo may move around document without update (say due to some compaction process). In that case we are not sure on consistency gurantee of natural order traversal i.e. is it possible that document may not get reflected in cursor result at all if Mongo is in use? So based on #1 we just need to ensure that sorting removes any duplicates > Ensure that all Documents are read with document order traversal indexing > - > > Key: OAK-7074 > URL: https://issues.apache.org/jira/browse/OAK-7074 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > With OAK-6353 support was added for document order traversal indexing. In > this mode we open a DB cursor and try to read all documents from it using > document order traversal. Such a cursor may remain open for long time (2-4 > hrs) and its possible that document may get reordered by the Mongo storage > engine. This would result in 2 aspects to be thought about > # Duplicate documents - Same document may appear more than once in result set > # Possibly missed document - It may be a possibility that a document got > moved and missed becoming part of cursor. > Both these aspects would need to be handled -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-7079) Enable oak-run indexing to connect to secondary node in Mongo replica set
Chetan Mehrotra created OAK-7079: Summary: Enable oak-run indexing to connect to secondary node in Mongo replica set Key: OAK-7079 URL: https://issues.apache.org/jira/browse/OAK-7079 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk, run Reporter: Chetan Mehrotra Fix For: 1.10 With OAK-6353 support for document order traversal based indexing has been added. Currently it connects to Mongo primary. We need to test and validate if it can be made only to connect to Mongo secondary for below 2 cases # Pre created checkpoint - Here checkpoint is created already and then oak-run *only* connects to Mongo secondary # Online indexing - Here oak-run would also create checkpoint. However it would need to be ensured that when it performs the document order traversal query that query is handled by Mongo secondary and oak-run logic ensures that secondary node has the created checkpoint -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6353) Use Document order traversal for reindexing performed on DocumentNodeStore setups
[ https://issues.apache.org/jira/browse/OAK-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294747#comment-16294747 ] Chetan Mehrotra edited comment on OAK-6353 at 12/19/17 5:41 AM: There are some aspects which still need to be taken care of. See OAK-7074 and OAK-7079 was (Author: chetanm): There are some aspects which still need to be taken care of. See OAK-7074 > Use Document order traversal for reindexing performed on DocumentNodeStore > setups > - > > Key: OAK-6353 > URL: https://issues.apache.org/jira/browse/OAK-6353 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.7.13, 1.8 > > Attachments: OAK-6353-v1.patch, OAK-6353-v2.patch > > > [~tmueller] suggested > [here|https://issues.apache.org/jira/browse/OAK-6246?focusedCommentId=16034442&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16034442] > that document order traversal can be faster compared to current mode of path > based traversal. Initial test indicate that such a traversal can be order of > magnitude faster. > So this task is meant to implement such an approach and see if it can be a > viable indexing mode used for DocumentNodeStore based setups -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-5885) segment-tar should have a tarmkrecovery command
[
https://issues.apache.org/jira/browse/OAK-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-5885:
--
Assignee: Michael Dürig
> segment-tar should have a tarmkrecovery command
> ---
>
> Key: OAK-5885
> URL: https://issues.apache.org/jira/browse/OAK-5885
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Michael Dürig
>Priority: Minor
> Labels: tooling
> Fix For: 1.8
>
>
> {{oak-segment}} had a {{tarmkrecovery}} command responsible with listing
> candidates for head journal entries. We should re-enable this also for
> {{oak-segment-tar}}.
> /cc [~mduerig] [~frm]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
