[jira] [Commented] (OAK-4978) Expose maintainence related MBeans for Segment NodeStores created via factory
[
https://issues.apache.org/jira/browse/OAK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682772#comment-15682772
]
Chetan Mehrotra commented on OAK-4978:
--
+1. Have the factory call SegmentNodeStoreService#activate. Only downside for
now would be that metatype for the factory would not be rich. But that should
be ok. This we can later address via new typed config support [1].
In doing this we should ensure that any singleton service registered (like JMX
MBeans) etc should be scoped to the role so as to allow multiple such services
to be registered.
[1] http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
> Expose maintainence related MBeans for Segment NodeStores created via factory
> -
>
> Key: OAK-4978
> URL: https://issues.apache.org/jira/browse/OAK-4978
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, segmentmk
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Fix For: 1.6
>
>
> With OAK-4655 support was added to initializing multiple segment nodestores
> and have them exposed via {{NodeStoreProvider}} ties to different roles.
> In some cases such stores are immutable and do not require any maintenance.
> However for other cases maintenance is required. So we would need to expose
> various MBean which allow such maintenance activities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4978) Expose maintainence related MBeans for Segment NodeStores created via factory
[
https://issues.apache.org/jira/browse/OAK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682760#comment-15682760
]
Alex Parvulescu commented on OAK-4978:
--
the amount of overlap in configs needed here is scary. could we remove all
properties from the factory and in some way have the
{{SegmentNodeStoreFactory}} call the {{SegmentNodeStoreService#activate}}
method with the current {{context}} and possibly some tweaked properties? this
way all segment store stuff would remain in the segment service and the factory
would just be responsible for activation of stores without caring
too much about the specifics.
> Expose maintainence related MBeans for Segment NodeStores created via factory
> -
>
> Key: OAK-4978
> URL: https://issues.apache.org/jira/browse/OAK-4978
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar, segmentmk
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Fix For: 1.6
>
>
> With OAK-4655 support was added to initializing multiple segment nodestores
> and have them exposed via {{NodeStoreProvider}} ties to different roles.
> In some cases such stores are immutable and do not require any maintenance.
> However for other cases maintenance is required. So we would need to expose
> various MBean which allow such maintenance activities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4939) Isolate corrupted index and make async indexer more resilient
[ https://issues.apache.org/jira/browse/OAK-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4939: - Description: Currently if any one of the async index gets corrupted it brings down the whole async indexer and no other index gets updated untill system administrator reindexes the problamatic async index. Instead of fail all we should isolate such corrupted index and mark them as corrupted. And still let async indexer progress for other working indexes. This would ensure that one corrupted index does not affect the whole system and allow the application to work partially. Feature branch - https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-4939?expand=1 was: Currently if any one of the async index gets corrupted it brings down the whole async indexer and no other index gets updated untill system administrator reindexes the problamatic async index. Instead of fail all we should isolate such corrupted index and mark them as corrupted. And still let async indexer progress for other working indexes. This would ensure that one corrupted index does not affect the whole system and allow the application to work partially. > Isolate corrupted index and make async indexer more resilient > - > > Key: OAK-4939 > URL: https://issues.apache.org/jira/browse/OAK-4939 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.6 > > > Currently if any one of the async index gets corrupted it brings down the > whole async indexer and no other index gets updated untill system > administrator reindexes the problamatic async index. > Instead of fail all we should isolate such corrupted index and mark them as > corrupted. And still let async indexer progress for other working indexes. > This would ensure that one corrupted index does not affect the whole system > and allow the application to work partially. > Feature branch - > https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-4939?expand=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5131) IndexDefinitionBuilder to allow for useInSpellcheck and useInSuggest
Vikas Saurabh created OAK-5131: -- Summary: IndexDefinitionBuilder to allow for useInSpellcheck and useInSuggest Key: OAK-5131 URL: https://issues.apache.org/jira/browse/OAK-5131 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Vikas Saurabh Assignee: Vikas Saurabh Priority: Minor Fix For: 1.6, 1.5.14 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4836) Avoid excessive logging in case of corrupt index or mis-configured index defnition
[ https://issues.apache.org/jira/browse/OAK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-4836. -- Resolution: Fixed Fix Version/s: 1.5.14 > Avoid excessive logging in case of corrupt index or mis-configured index > defnition > -- > > Key: OAK-4836 > URL: https://issues.apache.org/jira/browse/OAK-4836 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Vikas Saurabh >Assignee: Chetan Mehrotra > Fix For: 1.6, 1.5.14 > > > Following up from comment\[0] from [~chetanm] in OAK-4805, in case of corrupt > index or mis-configured index defnition the logs tend to fill up with same > exception over and over. It would be useful for index tracker to keep track > of such index and ignore those for any processing until some change is > detected on the definition (reindex would also lead to a change on index). > We might also want to expose a jmx which lists the indices that tracker > thinks are bad (and probably also why it started to think that). > \[0]: > https://issues.apache.org/jira/browse/OAK-4805?focusedCommentId=15492487=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15492487 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4836) Avoid excessive logging in case of corrupt index or mis-configured index defnition
[
https://issues.apache.org/jira/browse/OAK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681427#comment-15681427
]
Chetan Mehrotra commented on OAK-4836:
--
Same data would be accessible via {{LuceneIndexMBean}} (r1770372). If there is
any error in reading from index then {{failing}} attribute would be set to
{{true}}. This flag can be monitored as part of some health check
> Avoid excessive logging in case of corrupt index or mis-configured index
> defnition
> --
>
> Key: OAK-4836
> URL: https://issues.apache.org/jira/browse/OAK-4836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.14
>
>
> Following up from comment\[0] from [~chetanm] in OAK-4805, in case of corrupt
> index or mis-configured index defnition the logs tend to fill up with same
> exception over and over. It would be useful for index tracker to keep track
> of such index and ignore those for any processing until some change is
> detected on the definition (reindex would also lead to a change on index).
> We might also want to expose a jmx which lists the indices that tracker
> thinks are bad (and probably also why it started to think that).
> \[0]:
> https://issues.apache.org/jira/browse/OAK-4805?focusedCommentId=15492487=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15492487
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4836) Avoid excessive logging in case of corrupt index or mis-configured index defnition
[
https://issues.apache.org/jira/browse/OAK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681422#comment-15681422
]
Chetan Mehrotra commented on OAK-4836:
--
Introduced a {{BadIndexTracker}} (r1770371) which would keep track of bad
indexes. Upon detecting a bad index it would log a error log for the first time
{noformat}
2016-11-18 14:45:19,348 ERROR NA [FelixStartLevel]
o.a.j.o.p.i.l.BadIndexTracker - Could not access the Lucene index at
[/oak:index/lucene]
java.lang.AssertionError: numBytes=-13
at org.apache.lucene.store.DataOutput.copyBytes(DataOutput.java:244)
at org.apache.lucene.store.Directory.copy(Directory.java:186)
at
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.copyFilesToLocal(CopyOnReadDirectory.java:199)
{noformat}
Then for further access it would log at DEBUG level and the index would not be
accessed
{noformat}
2016-11-18 14:45:29,543 DEBUG admin [127.0.0.1 [1479460529454] GET
/libs/crx/core/content/welcome.html HTTP/1.1] o.a.j.o.p.i.l.BadIndexTracker -
Ignoring index [/oak:index/lucene] which is not working correctly since 10.20 s
,0 indexing cycles, accessed 1 times
{noformat}
Then after 15 min if the index is accessed then it would check again and in
case of failure would log an ERROR message. (Log below is for 1 min check in
test scenario)
{noformat}
2016-11-18 14:46:24,271 ERROR NA [qtp251997596-163]
o.a.j.o.p.i.l.BadIndexTracker - Could not access the Lucene index at
[/oak:index/lucene] . since 1.082 min ,0 indexing cycles, accessed 7 times
java.lang.AssertionError: numBytes=-13
at org.apache.lucene.store.DataOutput.copyBytes(DataOutput.java:244)
at org.apache.lucene.store.Directory.copy(Directory.java:186)
at
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.copyFilesToLocal(CopyOnReadDirectory.java:199)
at
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory.prefetchIndexFiles(CopyOnReadDirectory.java:170)
{noformat}
Later post reindexing when index starts working again then it would be detected
and an INFO level message would be logged and index would be used
{noformat}
2016-11-18 14:47:04,532 INFO NA [oak-lucene-1] o.a.j.o.p.i.l.BadIndexTracker -
Index [/oak:index/lucene] which was not working since 1.753 min ,1 indexing
cycles, accessed 8 times is found to be healthy again
{noformat}
> Avoid excessive logging in case of corrupt index or mis-configured index
> defnition
> --
>
> Key: OAK-4836
> URL: https://issues.apache.org/jira/browse/OAK-4836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Following up from comment\[0] from [~chetanm] in OAK-4805, in case of corrupt
> index or mis-configured index defnition the logs tend to fill up with same
> exception over and over. It would be useful for index tracker to keep track
> of such index and ignore those for any processing until some change is
> detected on the definition (reindex would also lead to a change on index).
> We might also want to expose a jmx which lists the indices that tracker
> thinks are bad (and probably also why it started to think that).
> \[0]:
> https://issues.apache.org/jira/browse/OAK-4805?focusedCommentId=15492487=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15492487
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2108) Killing a cluster node may stop async index update to to 30 minutes
[ https://issues.apache.org/jira/browse/OAK-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2108. -- Resolution: Fixed Fix Version/s: 1.5.14 > Killing a cluster node may stop async index update to to 30 minutes > --- > > Key: OAK-2108 > URL: https://issues.apache.org/jira/browse/OAK-2108 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Chetan Mehrotra > Labels: resilience > Fix For: 1.6, 1.5.14 > > Attachments: OAK-2108-v1.patch, OAK-2108-v2.patch > > > When killing a cluster node that is running the sync index update, then this > async index update will not run for up to 15 minutes, because the lease time > is set to 15 minutes. > I think the lease time should be much smaller, for example 1 minute, or maybe > even 10 seconds. > Also, we might need to better document this issue (in addition to the warning > in the log file). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2108) Killing a cluster node may stop async index update to to 30 minutes
[ https://issues.apache.org/jira/browse/OAK-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681408#comment-15681408 ] Chetan Mehrotra commented on OAK-2108: -- Thanks Alex!. The v2 patch is much more precise change and disables any lease related logic altogether. Applied the patch with r1770569 For non clusterable NodeStores like SegmentNodeStore there would not be any lease check performed. So in case of abrupt shutdown indexing would not get delayed > Killing a cluster node may stop async index update to to 30 minutes > --- > > Key: OAK-2108 > URL: https://issues.apache.org/jira/browse/OAK-2108 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Chetan Mehrotra > Labels: resilience > Fix For: 1.6, 1.5.14 > > Attachments: OAK-2108-v1.patch, OAK-2108-v2.patch > > > When killing a cluster node that is running the sync index update, then this > async index update will not run for up to 15 minutes, because the lease time > is set to 15 minutes. > I think the lease time should be much smaller, for example 1 minute, or maybe > even 10 seconds. > Also, we might need to better document this issue (in addition to the warning > in the log file). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4940) Consider collecting grand-parent changes in ChangeSet
[ https://issues.apache.org/jira/browse/OAK-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681366#comment-15681366 ] Chetan Mehrotra commented on OAK-4940: -- bq. I've now chosen two separate sets (parent and all) as that allows for slightly more precise filtering (and the set should still be small, so no large overhead expected) +1 Makes sense. Lets treat them distinctly > Consider collecting grand-parent changes in ChangeSet > - > > Key: OAK-4940 > URL: https://issues.apache.org/jira/browse/OAK-4940 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.6, 1.5.14 > > Attachments: OAK-4940.patch > > > At the moment the ChangeSet, which is populated by ChangeCollectorProvider (a > Validator) during a commit, collects changed property names, as well as node > name, node type and path of the parent (whereas _parent_ for a property > change is its node, while for a node change is actually its parent). > For improvements such as SLING-6163 it might be valuable to collect > grand-parent changes (node name, node type and perhaps path) too. We could > extend the ChangeSet with additional, explicit grand-parent sets (ie we > should not mix them with the parent changes as that would lessen filtering > rate) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3984) RDBDocumentStore: implement new conditional remove method
[ https://issues.apache.org/jira/browse/OAK-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681191#comment-15681191 ] Julian Reschke commented on OAK-3984: - Did some minor refactoring in [r1770561|http://svn.apache.org/r1770561]. > RDBDocumentStore: implement new conditional remove method > - > > Key: OAK-3984 > URL: https://issues.apache.org/jira/browse/OAK-3984 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.6, 1.5.14 > > > As introduced in OAK-3982. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5124) How do i include jackrabbit oak as a dependency inside a build.gradle file? And then use it in your project?
[
https://issues.apache.org/jira/browse/OAK-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680903#comment-15680903
]
Alex Parvulescu commented on OAK-5124:
--
bq. The only thing that jumps out at me as odd is why is there a 1.7 dependency
(sourceCompatibility = 1.7) the first thing I was going to try was setting this
to 1.8.
you can consider this an artefact of the example project, java 8 is perfectly
fine here.
bq. It would be awesome to have some comments in the build.gradle explaining
why all the dependencies are needed
those are simply the dependencies of oak itself
bq. I thought this was the only way to get items to go to the mailing list when
I tried emailing the list a few times and kept getting emails back
please try using 'oak-...@jackrabbit.apache.org' for your questions. there is a
filter against spam, so expect some delays for your first emails, but after you
should be fine.
> How do i include jackrabbit oak as a dependency inside a build.gradle file?
> And then use it in your project?
>
>
> Key: OAK-5124
> URL: https://issues.apache.org/jira/browse/OAK-5124
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: examples
>Affects Versions: 1.4.10
>Reporter: Charles Grossman
>Priority: Minor
>
> I've tried a few different things like
> buildscript {
> repositories {
> jcenter()
> mavenCentral()
> }
> dependencies {
>
> classpath 'org.apache.jackrabbit:oak-jcr:1.0.0'
> classpath 'javax.jcr:jcr:2.0'
> }
> }
> //these fail
> apply plugin: 'org.apache.jackrabbit:oak-jcr:1.0.0'
> apply plugin: 'javax.jcr:jcr:2.0'
> repositories {
> jcenter()
>mavenCentral()
> }
> but not really sure if this is the right idea at all.
> Does anyone have some github examples or have done any work with Gradle and
> jackrabbit Oak?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5124) How do i include jackrabbit oak as a dependency inside a build.gradle file? And then use it in your project?
[
https://issues.apache.org/jira/browse/OAK-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-5124.
--
Resolution: Not A Problem
> How do i include jackrabbit oak as a dependency inside a build.gradle file?
> And then use it in your project?
>
>
> Key: OAK-5124
> URL: https://issues.apache.org/jira/browse/OAK-5124
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: examples
>Affects Versions: 1.4.10
>Reporter: Charles Grossman
>Priority: Minor
>
> I've tried a few different things like
> buildscript {
> repositories {
> jcenter()
> mavenCentral()
> }
> dependencies {
>
> classpath 'org.apache.jackrabbit:oak-jcr:1.0.0'
> classpath 'javax.jcr:jcr:2.0'
> }
> }
> //these fail
> apply plugin: 'org.apache.jackrabbit:oak-jcr:1.0.0'
> apply plugin: 'javax.jcr:jcr:2.0'
> repositories {
> jcenter()
>mavenCentral()
> }
> but not really sure if this is the right idea at all.
> Does anyone have some github examples or have done any work with Gradle and
> jackrabbit Oak?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
