[jira] [Commented] (OAK-2500) checkDeepHistory/fixDeepHistory/prepareDeepHistory for oak-mongo.js
[ https://issues.apache.org/jira/browse/OAK-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358051#comment-14358051 ] Chetan Mehrotra commented on OAK-2500: -- bq. Chetan Mehrotra, would it make sense to include that in 1.0 branch? (as it affects 1.0.8 if I remember correctly) In all our docs we refer to the oak-mongo.js from trunk. So it should be fine to update it in trunk only [~mreutegg] Can you have a look? > checkDeepHistory/fixDeepHistory/prepareDeepHistory for oak-mongo.js > --- > > Key: OAK-2500 > URL: https://issues.apache.org/jira/browse/OAK-2500 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Affects Versions: 1.0.8 >Reporter: Stefan Egli > Fix For: 1.0.13 > > Attachments: oak-mongo-mod.js > > > The oak-mongo.js currently contains checkHistory/fixHistory which are > cleaning up 'dangling revisions/split-documents' on a particular path. > Now it would be good to have a command that goes through the entire > repository and checks/fixes these dangling revisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2287) ConflictHandler for merging jcr:lastModified
[ https://issues.apache.org/jira/browse/OAK-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357763#comment-14357763 ] Clinton H Goudie-Nice commented on OAK-2287: Is this issue moving ahead? This is a fix I would like to see. > ConflictHandler for merging jcr:lastModified > > > Key: OAK-2287 > URL: https://issues.apache.org/jira/browse/OAK-2287 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > Fix For: 1.2 > > Attachments: OAK-2287-2.patch, OAK-2287.patch > > > As discussed on oak-dev, 'jcr:lastModified' is a date property and it > represents the last modification date. It makes sense to merge concurrent > updates by picking the newer date of the 2 options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-1859) Migration from TarMK to MongoMK
[ https://issues.apache.org/jira/browse/OAK-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357374#comment-14357374 ] Manfred Baedke edited comment on OAK-1859 at 3/11/15 6:55 PM: -- Implemented in branch 1.0 with revision 1665962 and in trunk with revision 1665964. The new class RepositorySidegrade works analogously to RepositoryUpgrade. was (Author: baedke): Implemented in branch 1.0 with revision 1665962. > Migration from TarMK to MongoMK > --- > > Key: OAK-1859 > URL: https://issues.apache.org/jira/browse/OAK-1859 > Project: Jackrabbit Oak > Issue Type: Wish > Components: upgrade >Affects Versions: 1.0 >Reporter: Przemo Pakulski >Assignee: Manfred Baedke > Fix For: 1.2 > > > Is migration from TarMK to MongoMK possible ? > Let's say I initially used TarMK, then realized that Mongo is better option, > is there any way to migrate existing content to MongoDB ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1859) Migration from TarMK to MongoMK
[ https://issues.apache.org/jira/browse/OAK-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357374#comment-14357374 ] Manfred Baedke commented on OAK-1859: - Implemented in branch 1.0 with revision 1665962. > Migration from TarMK to MongoMK > --- > > Key: OAK-1859 > URL: https://issues.apache.org/jira/browse/OAK-1859 > Project: Jackrabbit Oak > Issue Type: Wish > Components: upgrade >Affects Versions: 1.0 >Reporter: Przemo Pakulski >Assignee: Manfred Baedke > Fix For: 1.2 > > > Is migration from TarMK to MongoMK possible ? > Let's say I initially used TarMK, then realized that Mongo is better option, > is there any way to migrate existing content to MongoDB ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2539) SQL2 query not working with filter (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b'))
[ https://issues.apache.org/jira/browse/OAK-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Calvin Wong updated OAK-2539: - Description: Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. Add 2 String properties: stringa = "a", stringb = "b". Use query tool in CRX/DE to do SQL2 search: This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b')) This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (CONTAINS(s.[stringb], 'b')) This search will not find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR CONTAINS(s.[stringb], 'b')) was: Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. Add 2 String properties: stringa = "a", stringb = "b". User query tool in CRX/DE to do SQL2 search: This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b')) This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (CONTAINS(s.[stringb], 'b')) This search will not find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR CONTAINS(s.[stringb], 'b')) > SQL2 query not working with filter (s.[stringa] = 'a' OR > CONTAINS(s.[stringb], 'b')) > > > Key: OAK-2539 > URL: https://issues.apache.org/jira/browse/OAK-2539 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Calvin Wong >Assignee: Davide Giannella > Fix For: 1.1.8 > > > Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. > Add 2 String properties: stringa = "a", stringb = "b". > Use query tool in CRX/DE to do SQL2 search: > This search will find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR > CONTAINS(s.[stringb], 'b')) > This search will find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (CONTAINS(s.[stringb], 'b')) > This search will not find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR > CONTAINS(s.[stringb], 'b')) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2539) SQL2 query not working with filter (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b'))
[ https://issues.apache.org/jira/browse/OAK-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Calvin Wong updated OAK-2539: - Description: Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. Add 2 String properties: stringa = "a", stringb = "b". User query tool in CRX/DE to do SQL2 search: This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b')) This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (CONTAINS(s.[stringb], 'b')) This search will not find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR CONTAINS(s.[stringb], 'b')) was: Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. Add 2 String properties: stringa = "a", stringb = "b". User query tool in CRX/DE to do SQL2 search: This search will find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR CONTAINS(s.[stringb], 'b')) This search will not find qtest: SELECT * FROM [nt:base] AS s WHERE ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR CONTAINS(s.[stringb], 'b')) > SQL2 query not working with filter (s.[stringa] = 'a' OR > CONTAINS(s.[stringb], 'b')) > > > Key: OAK-2539 > URL: https://issues.apache.org/jira/browse/OAK-2539 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Calvin Wong >Assignee: Davide Giannella > Fix For: 1.1.8 > > > Create node /content/usergenerated/qtest with jcr:primaryType nt:unstrucuted. > Add 2 String properties: stringa = "a", stringb = "b". > User query tool in CRX/DE to do SQL2 search: > This search will find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'a' OR > CONTAINS(s.[stringb], 'b')) > This search will find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (CONTAINS(s.[stringb], 'b')) > This search will not find qtest: > SELECT * FROM [nt:base] AS s WHERE > ISDESCENDANTNODE([/content/usergenerated/]) AND (s.[stringa] = 'x' OR > CONTAINS(s.[stringb], 'b')) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2560) SegmentStore deadlock on shutdown
[
https://issues.apache.org/jira/browse/OAK-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357205#comment-14357205
]
Michael Dürig commented on OAK-2560:
Although not explicitly stated, I think the only reasonable semantics for
{{SegmentStore#close}} is that clients may not use the store any more as soon
as {{close}} is being called. From this POV the async indexer is at fault here.
Looking at how things are set up I think it should be the responsibility of
{{SegmenNodeStoreService}} to properly brings down everything that relies on
the store before closing the store. This means that 1)
{{Oak#createContentRepository}} is the wrong place to hook up the async index
updater and 2) the async indexer needs a way so we can preemptively interrupt
it.
> SegmentStore deadlock on shutdown
> -
>
> Key: OAK-2560
> URL: https://issues.apache.org/jira/browse/OAK-2560
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.2
>
>
> We've ran into a deadlock in the Oak SegmentNodeStore between
> _org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.deactivate(SegmentNodeStoreService.java:300)_
> and _
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)_
> This was seen on Oak 1.0.11.
> {code}
> Java stack information for the threads listed above
>
> "pool-9-thread-5":
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:656)
> - waiting to lock <0x000680024468> (a
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:101)
> - locked <0x0006b0b7ae28> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentId)
> at
> org.apache.jackrabbit.oak.plugins.segment.Record.getSegment(Record.java:82)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.size(MapRecord.java:128)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:462)
> - locked <0x000680c634a8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:460)
> - locked <0x000680c634a8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMap(SegmentWriter.java:660)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1020)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1022)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.getNodeState(SegmentNodeBuilder.java:91)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:77)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.updated(MemoryNodeBuilder.java:204)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:73)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:331)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:323)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:311)
> at
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.insert(ContentMirrorStoreStrategy.java:112)
> at
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirrorStoreStrategy.java:81)
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.leave(PropertyIndexEditor.java:261)
> at
> org.apache.jackrabbit.oak.spi.commit.
[jira] [Commented] (OAK-2448) Do not create nodeChildren cache entry for leaf
[ https://issues.apache.org/jira/browse/OAK-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357073#comment-14357073 ] Chetan Mehrotra commented on OAK-2448: -- Merged to 1.0 with http://svn.apache.org/r1665908 > Do not create nodeChildren cache entry for leaf > --- > > Key: OAK-2448 > URL: https://issues.apache.org/jira/browse/OAK-2448 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.1.6, 1.0.13 > > > Currently the DocumentNodeStore populates nodeChildrenCache after a commit > with entries for leaf nodes. Those cache entries all have a zero length list > and are unnecessary, because the underlying document already has a flag, > which indicates whether the node is a leaf. The cache entries created for > leaf nodes are never used and only flood the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2464) Optimize read of known non-existing children
[
https://issues.apache.org/jira/browse/OAK-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2464:
-
Fix Version/s: 1.0.13
> Optimize read of known non-existing children
>
>
> Key: OAK-2464
> URL: https://issues.apache.org/jira/browse/OAK-2464
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6, 1.0.13
>
> Attachments:
> 0001-OAK-2464-Optimize-read-of-known-non-existing-childre.patch,
> OAK-2464-Sort order test case.patch, OAK-2464-Take2.patch
>
>
> Reading a non-existing node always queries down to {{DocumentStore}}.
> {{DocumentNodeStore}} should consider {{nodeChildrenCache}} to see if it
> already knows about non-existence and avoid a look up into {{DocumentStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2608) Avoid indexing user/group/uuid props by default
[ https://issues.apache.org/jira/browse/OAK-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-2608. -- Resolution: Fixed fixed in r1665910 (trunk) and r1665914 (branch 1.0) > Avoid indexing user/group/uuid props by default > --- > > Key: OAK-2608 > URL: https://issues.apache.org/jira/browse/OAK-2608 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-solr >Affects Versions: 1.1.7 >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.1.8, 1.0.13 > > > Properties like _rep:authorizableId, rep:princitpalName, jcr:uuid, > rep:members_ are mostly handled by other types of sync indexes, therefore > it'd be better to ignore them (both on indexing and searching side) in the > Solr index by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2607) OakSolrConfigurationProviderService wrongly uses ignoredProperties for usedProperties
[
https://issues.apache.org/jira/browse/OAK-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-2607.
--
Resolution: Fixed
fixed in r1665897 (trunk) and r1665912 (branch 1.0)
> OakSolrConfigurationProviderService wrongly uses ignoredProperties for
> usedProperties
> -
>
> Key: OAK-2607
> URL: https://issues.apache.org/jira/browse/OAK-2607
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-solr
>Affects Versions: 1.1.7
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.1.8, 1.0.13
>
>
> {{OakSolrConfigurationProviderService#getIgnoredProperties}} wrongly uses the
> _usedProperties_ variable instead of the _ignoredProperties_ one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2560) SegmentStore deadlock on shutdown
[
https://issues.apache.org/jira/browse/OAK-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357080#comment-14357080
]
Alex Parvulescu commented on OAK-2560:
--
So this boils down to
{code}
SegmentNodeStoreService#deactivate
- FileStore#close locks [FileStore] with <6800>
- FileStore#flush locks [FileStore#persistedHead] with <6846>
- tracker.getWriter().flush() waits on [SegmentWriter] <680c>
SegmentWriter#writeMap
- SegmentWriter#writeMapBucket locks [SegmentWriter] with <680c>
- SegmentId#getSegment locks [SegmentId] with <6b0b>
- SegmentTracker#getSegment
- FileStore#readSegment waits on [FileStore] <6800>
{code}
but the problem is I'm not really convinced that the lock order is the problem.
I think the problem is the fact that the FileStore is closing and there's no
way to prevent others from continuing with loading segments. So basically a
#readSegment call after a #close call should be considered illegal.
[~mduerig] thoughts?
> SegmentStore deadlock on shutdown
> -
>
> Key: OAK-2560
> URL: https://issues.apache.org/jira/browse/OAK-2560
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.2
>
>
> We've ran into a deadlock in the Oak SegmentNodeStore between
> _org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.deactivate(SegmentNodeStoreService.java:300)_
> and _
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)_
> This was seen on Oak 1.0.11.
> {code}
> Java stack information for the threads listed above
>
> "pool-9-thread-5":
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:656)
> - waiting to lock <0x000680024468> (a
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.getSegment(SegmentTracker.java:120)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:101)
> - locked <0x0006b0b7ae28> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentId)
> at
> org.apache.jackrabbit.oak.plugins.segment.Record.getSegment(Record.java:82)
> at
> org.apache.jackrabbit.oak.plugins.segment.MapRecord.size(MapRecord.java:128)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:462)
> - locked <0x000680c634a8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMapBucket(SegmentWriter.java:460)
> - locked <0x000680c634a8> (a
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeMap(SegmentWriter.java:660)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1020)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:1022)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter$2.childNodeChanged(SegmentWriter.java:1003)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.writeNode(SegmentWriter.java:994)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.getNodeState(SegmentNodeBuilder.java:91)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:77)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.updated(MemoryNodeBuilder.java:204)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeBuilder.updated(SegmentNodeBuilder.java:73)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:331)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNode(MemoryNodeBuilder.java:323)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.child(MemoryNodeBuilder.java:311)
> at
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.insert(ContentMirrorStoreStrategy.java:112)
> at
> org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy.update(ContentMirror
[jira] [Updated] (OAK-2404) Provide more information in SegmentNotFoundException
[
https://issues.apache.org/jira/browse/OAK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-2404:
---
Attachment: OAK-2404.patch
[^OAK-2404.patch] logs the segment ids of the segments removed by cleanup. When
testing this on a medium sized repository with a lot of garbage (12GB
compactable to 2GB) the extra amount of logging is 4MB spread over 26000 log
lines. On average I've seen 550 log lines per cleaned tar file.
How should we handle this amount of extra information? I already log to a
different logger so applications could redirect this to a dedicated appender.
Currently the log level is at INFO as I figure we want to have this information
per default. But still I fear the people come back shouting spam when I check
this in. WDYT?
cc [~alex.parvulescu], [~mmarth]
> Provide more information in SegmentNotFoundException
>
>
> Key: OAK-2404
> URL: https://issues.apache.org/jira/browse/OAK-2404
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: gc, monitoring
> Fix For: 1.0.13, 1.2
>
> Attachments: OAK-2404.patch
>
>
> There is currently no way to distinguish between a
> {{SegmentNotFoundException}} occurring because of a removed segment by gc or
> because of another corruption. Optimally we would tell in the exception why
> the segment is gone, how old it was when gc removed it and who/what was still
> referring to it at that time. In order to do that, we probably need some kind
> of log for the following data: When a segment was removed (because a new
> generation of the .tar file was made, or because the .tar file was removed),
> we should log the segment, the file name, and the date+time of the removal.
> If the segment was then not found because it was too old, then another type
> of exception should be thrown instead, for example "ReadTimeoutException",
> with a message that contains as much data as possible: the data+time of the
> segment, date+time of the removal of the segment, about when compaction was
> run, date+time of the session login and last refresh, the stack trace of
> where the session was acquired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2448) Do not create nodeChildren cache entry for leaf
[ https://issues.apache.org/jira/browse/OAK-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2448: - Fix Version/s: 1.0.13 > Do not create nodeChildren cache entry for leaf > --- > > Key: OAK-2448 > URL: https://issues.apache.org/jira/browse/OAK-2448 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.1.6, 1.0.13 > > > Currently the DocumentNodeStore populates nodeChildrenCache after a commit > with entries for leaf nodes. Those cache entries all have a zero length list > and are unnecessary, because the underlying document already has a flag, > which indicates whether the node is a leaf. The cache entries created for > leaf nodes are never used and only flood the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2608) Avoid indexing user/group/uuid props by default
Tommaso Teofili created OAK-2608: Summary: Avoid indexing user/group/uuid props by default Key: OAK-2608 URL: https://issues.apache.org/jira/browse/OAK-2608 Project: Jackrabbit Oak Issue Type: Improvement Components: oak-solr Affects Versions: 1.1.7 Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.1.8, 1.0.13 Properties like _rep:authorizableId, rep:princitpalName, jcr:uuid, rep:members_ are mostly handled by other types of sync indexes, therefore it'd be better to ignore them (both on indexing and searching side) in the Solr index by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2464) Optimize read of known non-existing children
[
https://issues.apache.org/jira/browse/OAK-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357018#comment-14357018
]
Marcel Reutegger commented on OAK-2464:
---
Yes, looks fine from my POV.
> Optimize read of known non-existing children
>
>
> Key: OAK-2464
> URL: https://issues.apache.org/jira/browse/OAK-2464
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments:
> 0001-OAK-2464-Optimize-read-of-known-non-existing-childre.patch,
> OAK-2464-Sort order test case.patch, OAK-2464-Take2.patch
>
>
> Reading a non-existing node always queries down to {{DocumentStore}}.
> {{DocumentNodeStore}} should consider {{nodeChildrenCache}} to see if it
> already knows about non-existence and avoid a look up into {{DocumentStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2607) OakSolrConfigurationProviderService wrongly uses ignoredProperties for usedProperties
[
https://issues.apache.org/jira/browse/OAK-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated OAK-2607:
-
Fix Version/s: 1.0.13
> OakSolrConfigurationProviderService wrongly uses ignoredProperties for
> usedProperties
> -
>
> Key: OAK-2607
> URL: https://issues.apache.org/jira/browse/OAK-2607
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-solr
>Affects Versions: 1.1.7
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.1.8, 1.0.13
>
>
> {{OakSolrConfigurationProviderService#getIgnoredProperties}} wrongly uses the
> _usedProperties_ variable instead of the _ignoredProperties_ one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2607) OakSolrConfigurationProviderService wrongly uses ignoredProperties for usedProperties
Tommaso Teofili created OAK-2607:
Summary: OakSolrConfigurationProviderService wrongly uses
ignoredProperties for usedProperties
Key: OAK-2607
URL: https://issues.apache.org/jira/browse/OAK-2607
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-solr
Affects Versions: 1.1.7
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Fix For: 1.1.8
{{OakSolrConfigurationProviderService#getIgnoredProperties}} wrongly uses the
_usedProperties_ variable instead of the _ignoredProperties_ one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2464) Optimize read of known non-existing children
[
https://issues.apache.org/jira/browse/OAK-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2464:
Fix Version/s: (was: 1.0.13)
> Optimize read of known non-existing children
>
>
> Key: OAK-2464
> URL: https://issues.apache.org/jira/browse/OAK-2464
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments:
> 0001-OAK-2464-Optimize-read-of-known-non-existing-childre.patch,
> OAK-2464-Sort order test case.patch, OAK-2464-Take2.patch
>
>
> Reading a non-existing node always queries down to {{DocumentStore}}.
> {{DocumentNodeStore}} should consider {{nodeChildrenCache}} to see if it
> already knows about non-existence and avoid a look up into {{DocumentStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2464) Optimize read of known non-existing children
[
https://issues.apache.org/jira/browse/OAK-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356901#comment-14356901
]
Julian Reschke edited comment on OAK-2464 at 3/11/15 2:21 PM:
--
This change causes a reproducible failure on my systems:
addNodeGetNode(org.apache.jackrabbit.oak.plugins.document.SimpleTest) Time
elapsed: 0.453 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at
org.apache.jackrabbit.oak.plugins.document.SimpleTest.addNodeGetNode(SimpleTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
[~chetanm], [~egli]: removed "fix version 1.0.13" and backing out the change
for now
was (Author: reschke):
This change causes a reproducible failure on my systems:
addNodeGetNode(org.apache.jackrabbit.oak.plugins.document.SimpleTest) Time
elapsed: 0.453 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at
org.apache.jackrabbit.oak.plugins.document.SimpleTest.addNodeGetNode(SimpleTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
[~chetanm] removed "fix version 1.0.13" and backing out the change for now
> Optimize read of known non-existing children
>
>
> Key: OAK-2464
> URL: https://issues.apache.org/jira/browse/OAK-2464
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.1.6
>
> Attachments:
> 0001-OAK-2464-Optimize-read-of-known-non-existing-childre.patch,
> OAK-2464-Sort order test case.patch, OAK-2464-Take2.patch
>
>
> Reading a non-existing node always queries down to {{DocumentStore}}.
> {{DocumentNodeStore}} should consider {{nodeChildrenCache}} to see if it
> already knows about non-existence and avoid a look up into {{DocumentStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2602) [Solr] Cost calculation takes time with solr pings even when not fulfilling query
[
https://issues.apache.org/jira/browse/OAK-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356879#comment-14356879
]
Tommaso Teofili edited comment on OAK-2602 at 3/11/15 1:50 PM:
---
This is due to the fact that currently the {{SolrQueryIndex}} is only returned
if the underlying {{SolrServer}} is alive, that is when a _ping_ request
returns _0_, then the {{SolrQueryIndex}} is used to evaluate the cost of JCR
queries even if then it won't be used (e.g. returning a cost higher than at
least one of the other available indexes), behaving just like other existing
Oak indexes.
What I see is:
1. if ping requests take time it may be that the Solr instance(s) used are
under high load or simply slow in responding for some reason
2. before OAK-2537 there were Solr queries executed for the cost calculation
(for the estimation of entries) so maybe some time got wasted there, now that
should not cause further performance issues.
3. we may choose to remove the ping calls before returning the
{{SolrQueryIndex}} (it also applies to {{SolrIndexEditor}} and
{{SolrIndexEditorProvider}}) in {{SolrQueryIndexProvider}} at the cost of
eventually start getting errors in query executions if the underlying Solr
server is unreachable.
was (Author: teofili):
This is due to the fact that currently the {{SolrQueryIndex}} is only returned
if the underlying {{SolrServer}} is alive, that is when a _ping_ request
returns _0_, then the {{SolrQueryIndex}} is used to evaluate the cost of JCR
queries even if then it won't be used (e.g. returning a cost higher than at
least one of the other available indexes), however this is by design.
What I see is:
1. if ping requests take time it may be that the Solr instance(s) used are
under high load or simply slow in responding for some reason
2. before OAK-2537 there were Solr queries executed for the cost calculation
(for the estimation of entries) so maybe some time got wasted there, now that
should not cause further performance issues.
3. we may choose to remove the ping calls before returning the
{{SolrQueryIndex}} (it also applies to {{SolrIndexEditor}} and
{{SolrIndexEditorProvider}}) in {{SolrQueryIndexProvider}} at the cost of
eventually start getting errors in query executions if the underlying Solr
server is unreachable.
> [Solr] Cost calculation takes time with solr pings even when not fulfilling
> query
> -
>
> Key: OAK-2602
> URL: https://issues.apache.org/jira/browse/OAK-2602
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Affects Versions: 1.0.12, 1.1.7
>Reporter: Amit Jain
>Assignee: Tommaso Teofili
> Fix For: 1.1.8, 1.0.13
>
>
> Cost calculation for queries which are fired quite often [1] and which are
> not going to fulfilled by solr take time due to which the overall cost of the
> operation is high.
> [1]
> SELECT * FROM [nt:base] WHERE PROPERTY([rep:members], 'WeakReference') =
> $uuid
> SELECT * FROM [nt:base] WHERE [jcr:uuid] = $id
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2602) [Solr] Cost calculation takes time with solr pings even when not fulfilling query
[
https://issues.apache.org/jira/browse/OAK-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356879#comment-14356879
]
Tommaso Teofili commented on OAK-2602:
--
This is due to the fact that currently the {{SolrQueryIndex}} is only returned
if the underlying {{SolrServer}} is alive, that is when a _ping_ request
returns _0_, then the {{SolrQueryIndex}} is used to evaluate the cost of JCR
queries even if then it won't be used (e.g. returning a cost higher than at
least one of the other available indexes), however this is by design.
What I see is:
1. if ping requests take time it may be that the Solr instance(s) used are
under high load or simply slow in responding for some reason
2. before OAK-2537 there were Solr queries executed for the cost calculation
(for the estimation of entries) so maybe some time got wasted there, now that
should not cause further performance issues.
3. we may choose to remove the ping calls before returning the
{{SolrQueryIndex}} (it also applies to {{SolrIndexEditor}} and
{{SolrIndexEditorProvider}}) in {{SolrQueryIndexProvider}} at the cost of
eventually start getting errors in query executions if the underlying Solr
server is unreachable.
> [Solr] Cost calculation takes time with solr pings even when not fulfilling
> query
> -
>
> Key: OAK-2602
> URL: https://issues.apache.org/jira/browse/OAK-2602
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Affects Versions: 1.0.12, 1.1.7
>Reporter: Amit Jain
>Assignee: Tommaso Teofili
> Fix For: 1.1.8, 1.0.13
>
>
> Cost calculation for queries which are fired quite often [1] and which are
> not going to fulfilled by solr take time due to which the overall cost of the
> operation is high.
> [1]
> SELECT * FROM [nt:base] WHERE PROPERTY([rep:members], 'WeakReference') =
> $uuid
> SELECT * FROM [nt:base] WHERE [jcr:uuid] = $id
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2570) Open indexes in IndexTracker non blocking way
[
https://issues.apache.org/jira/browse/OAK-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356834#comment-14356834
]
Julian Reschke commented on OAK-2570:
-
[~chetanm]] LuceneSupportTest frequently fails here with:
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.925 sec <<<
FAILURE!
fullTextSearch(org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest) Time
elapsed: 14.888 sec <<< FAILURE!
java.lang.AssertionError: RetryLoop failed, condition is false after 10 seconds:
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert$fail.callStatic(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:53)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:157)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:165)
at
org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest.retry(LuceneSupportTest.groovy:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at
org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:148)
> Open indexes in IndexTracker non blocking way
> -
>
> Key: OAK-2570
> URL: https://issues.apache.org/jira/browse/OAK-2570
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.1.8, 1.0.13
>
> Attachments: OAK-2570.patch
>
>
> Currently {{IndexTracker}} opens the indexes in same thread where the commit
> happens as it acts as an {{Observer}}. If opening the index takes long time
> it would block the commit thread and might introduce delay in other operation
> on same thread.
> For example {{DocumentNodeStore}} invokes the {{Observer}} in
> {{backgroundRead}} and that call would not complete unless the {{Observer}}
> returns back. For a system to be responsive the {{backgroundRead}} has to be
> quick as it holds the write lock. Due to current implementation at time
> system turn unresponsive.
> Looking at the threaddump from one such unresponsive system it appears that
> slowness is due to Lucene index taking time to reopen.
> Thread which hold the {{backgroundOperationLock}} for {{read}} is
> {noformat}
> "pool-9-thread-1" Id=101 in RUNNABLE
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:146)
> at
> org.apache.jackrabbit.core.data.LazyFileInputStream.open(LazyFileInputStream.java:104)
> at
> org.apache.jackrabbit.core.data.LazyFileInputStream.read(LazyFileInputStream.java:163)
> at com.google.common.io.ByteStreams.read(ByteStreams.java:828)
> at com.google.common.io.ByteStreams.readFully(ByteStreams.java:695)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.OakDirectory$OakIndexFile.loadBlob(OakDirectory.java:218)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.OakDirectory$OakIndexFile.readBytes(OakDirectory.java:264)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.OakDirectory$OakIndexInput.readBytes(OakDirectory.java:350)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.OakDirectory$OakIndexInput.readByte(OakDirectory.java:356)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:84)
> at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:126)
> at org.apache.lucene.util.fst.FST.(FST.java:318)
> at org.apache.lucene.util.fst.FST.(FST.java:304)
> at
> org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader.(BlockTreeTermsReader.java:484)
> at
> org.apache.lucene.codecs.BlockTreeTermsReader.(BlockTreeTermsReader.java:176)
> at
> org.apache.lucene.codecs.lucene41.Lucene41PostingsFormat.fieldsProducer(Lucene41PostingsFormat.java:437)
> at
> org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:116)
> at org.apache.lucene.index.SegmentReader.(SegmentReader.java:96)
> at
> org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:62)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:843)
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:52)
> at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:66)
> a
[jira] [Commented] (OAK-2596) more (jmx) instrumentation for observation queue
[
https://issues.apache.org/jira/browse/OAK-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356826#comment-14356826
]
Michael Dürig commented on OAK-2596:
* re. 1. and 2.: we could expose the information as time series through
{{EventListenerMBean}}. It would however depend on a fix in Jackrabbit (JCR) as
the implementation resides there.
* re. 3.: there is no way for the listener to know this as it doesn't know
about the backend. On the SegmentMK there isn't even a cache involved. Maybe
there are ways to expose such information from the DocumentMK diff chache
([~mreutegg])?
* re. 4.: I think this should be done through tooling on top of the available
MBeans (e.g. EventListenerMBean).
> more (jmx) instrumentation for observation queue
>
>
> Key: OAK-2596
> URL: https://issues.apache.org/jira/browse/OAK-2596
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.0.12
>Reporter: Stefan Egli
>Assignee: Michael Dürig
> Labels: monitoring, observation
> Fix For: 1.0.13
>
>
> While debugging issues with the observation queue it would be handy to have
> more detailed information available. At the moment you can only see one value
> wrt length of the queue: that is the maximum of all queues. It is unclear if
> the queue is that long for only one or many listeners. And it is unclear from
> that if the listener is slow or the engine that produces the events for the
> listener.
> So I'd suggest to add the following details - possible exposed via JMX? :
> # add queue length details to each of the observation listeners
> # have a history of the last, eg 1000 events per listener showing a) how long
> the event took to be created/generated and b) how long the listener took to
> process. Sometimes averages are not detailed enough so such a in-depth
> information might become useful. (Not sure about the feasibility of '1000'
> here - maybe that could be configurable though - just putting the idea out
> here).
> # have some information about whether a listener is currently 'reading events
> from the cache' or whether it has to go to eg mongo
> # maybe have a 'top 10' listeners that have the largest queue at the moment
> to easily allow navigation instead of having to go through all (eg 200)
> listeners manually each time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2596) more (jmx) instrumentation for observation queue
[ https://issues.apache.org/jira/browse/OAK-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2596: --- Description: While debugging issues with the observation queue it would be handy to have more detailed information available. At the moment you can only see one value wrt length of the queue: that is the maximum of all queues. It is unclear if the queue is that long for only one or many listeners. And it is unclear from that if the listener is slow or the engine that produces the events for the listener. So I'd suggest to add the following details - possible exposed via JMX? : # add queue length details to each of the observation listeners # have a history of the last, eg 1000 events per listener showing a) how long the event took to be created/generated and b) how long the listener took to process. Sometimes averages are not detailed enough so such a in-depth information might become useful. (Not sure about the feasibility of '1000' here - maybe that could be configurable though - just putting the idea out here). # have some information about whether a listener is currently 'reading events from the cache' or whether it has to go to eg mongo # maybe have a 'top 10' listeners that have the largest queue at the moment to easily allow navigation instead of having to go through all (eg 200) listeners manually each time. was: While debugging issues with the observation queue it would be handy to have more detailed information available. At the moment you can only see one value wrt length of the queue: that is the maximum of all queues. It is unclear if the queue is that long for only one or many listeners. And it is unclear from that if the listener is slow or the engine that produces the events for the listener. So I'd suggest to add the following details - possible exposed via JMX? : * add queue length details to each of the observation listeners * have a history of the last, eg 1000 events per listener showing a) how long the event took to be created/generated and b) how long the listener took to process. Sometimes averages are not detailed enough so such a in-depth information might become useful. (Not sure about the feasibility of '1000' here - maybe that could be configurable though - just putting the idea out here). ** have some information about whether a listener is currently 'reading events from the cache' or whether it has to go to eg mongo * maybe have a 'top 10' listeners that have the largest queue at the moment to easily allow navigation instead of having to go through all (eg 200) listeners manually each time. > more (jmx) instrumentation for observation queue > > > Key: OAK-2596 > URL: https://issues.apache.org/jira/browse/OAK-2596 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.12 >Reporter: Stefan Egli >Assignee: Michael Dürig > Labels: monitoring, observation > Fix For: 1.0.13 > > > While debugging issues with the observation queue it would be handy to have > more detailed information available. At the moment you can only see one value > wrt length of the queue: that is the maximum of all queues. It is unclear if > the queue is that long for only one or many listeners. And it is unclear from > that if the listener is slow or the engine that produces the events for the > listener. > So I'd suggest to add the following details - possible exposed via JMX? : > # add queue length details to each of the observation listeners > # have a history of the last, eg 1000 events per listener showing a) how long > the event took to be created/generated and b) how long the listener took to > process. Sometimes averages are not detailed enough so such a in-depth > information might become useful. (Not sure about the feasibility of '1000' > here - maybe that could be configurable though - just putting the idea out > here). > # have some information about whether a listener is currently 'reading events > from the cache' or whether it has to go to eg mongo > # maybe have a 'top 10' listeners that have the largest queue at the moment > to easily allow navigation instead of having to go through all (eg 200) > listeners manually each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2604) Backport LMSEstimator and sorting capabilities to branch 1.0
[
https://issues.apache.org/jira/browse/OAK-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-2604.
--
Resolution: Fixed
fixed in r1665861
> Backport LMSEstimator and sorting capabilities to branch 1.0
>
>
> Key: OAK-2604
> URL: https://issues.apache.org/jira/browse/OAK-2604
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.0.13
>
>
> Current estimation algorithm for {{AdvancedSolrQueryIndex}} is not smart as
> it also involves making a query which doesn't take into account the given
> filter, therefore the {{LMSEstimator}} which works better and is more
> performant should be backported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2604) Backport LMSEstimator and sorting capabilities to branch 1.0
[
https://issues.apache.org/jira/browse/OAK-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356796#comment-14356796
]
Tommaso Teofili edited comment on OAK-2604 at 3/11/15 12:18 PM:
this involves backporting OAK-2292 and OAK-2537
was (Author: teofili):
this involves backporting also OAK-2292 and OAK-2537
> Backport LMSEstimator and sorting capabilities to branch 1.0
>
>
> Key: OAK-2604
> URL: https://issues.apache.org/jira/browse/OAK-2604
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.0.13
>
>
> Current estimation algorithm for {{AdvancedSolrQueryIndex}} is not smart as
> it also involves making a query which doesn't take into account the given
> filter, therefore the {{LMSEstimator}} which works better and is more
> performant should be backported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2604) Backport LMSEstimator and sorting capabilities to branch 1.0
[
https://issues.apache.org/jira/browse/OAK-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated OAK-2604:
-
Summary: Backport LMSEstimator and sorting capabilities to branch 1.0
(was: Backport LMSEstimator to branch 1.0)
> Backport LMSEstimator and sorting capabilities to branch 1.0
>
>
> Key: OAK-2604
> URL: https://issues.apache.org/jira/browse/OAK-2604
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.0.13
>
>
> Current estimation algorithm for {{AdvancedSolrQueryIndex}} is not smart as
> it also involves making a query which doesn't take into account the given
> filter, therefore the {{LMSEstimator}} which works better and is more
> performant should be backported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2605) Support for additional encodings needed in ReversedLinesFileReader
[ https://issues.apache.org/jira/browse/OAK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356798#comment-14356798 ] Leandro Reis commented on OAK-2605: --- Awesome, [~mduerig], thanks a lot for your help with this. > Support for additional encodings needed in ReversedLinesFileReader > -- > > Key: OAK-2605 > URL: https://issues.apache.org/jira/browse/OAK-2605 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Affects Versions: 1.1.7 > Environment: Windows 2012 R2 Japanese > Windows 2012 R2 Korean > Windows 2012 R2 Simplified Chinese > Windows 2012 R2 Traditional Chinese >Reporter: Leandro Reis >Assignee: Michael Dürig > Fix For: 1.1.8 > > Attachments: OAK-2605.patch > > > I'm working on a product that uses Commons IO via Jackrabbit Oak. In the > process of testing the launch of such product on Japanese Windows 2012 > Server R2, I came across the following exception: > "(java.io.UnsupportedEncodingException: Encoding windows-31j is not supported > yet (feel free to submit a patch))" > windows-31j is the IANA name for Windows code page 932 (Japanese), and is > returned by Charset.defaultCharset(), used in > org.apache.commons.io.input.ReversedLinesFileReader [0]. > A patch for this issue was provided in > https://issues.apache.org/jira/browse/IO-471 . > It also includes changes needed to support Chinese Simplified, Chinese > Traditional and Korean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2604) Backport LMSEstimator to branch 1.0
[
https://issues.apache.org/jira/browse/OAK-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356796#comment-14356796
]
Tommaso Teofili commented on OAK-2604:
--
this involves backporting also OAK-2292 and OAK-2537
> Backport LMSEstimator to branch 1.0
> ---
>
> Key: OAK-2604
> URL: https://issues.apache.org/jira/browse/OAK-2604
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.0.13
>
>
> Current estimation algorithm for {{AdvancedSolrQueryIndex}} is not smart as
> it also involves making a query which doesn't take into account the given
> filter, therefore the {{LMSEstimator}} which works better and is more
> performant should be backported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2557) VersionGC uses way too much memory if there is a large pile of garbage
[
https://issues.apache.org/jira/browse/OAK-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356751#comment-14356751
]
Chetan Mehrotra edited comment on OAK-2557 at 3/11/15 11:38 AM:
[patch2|^OAK-2557-2.patch] which uses {{ExternalSort}} to sort the DocumentId.
It uses in memory approach for upto 100k ids. If more than that limit are to be
deleted then it switches to {{ExternalSort}}
[~egli] [~mreutegg] Can you have a look
[~amitjain] Can you review the usage of ExternalSort as this was also used in
Blob GC. So your feedback would be helpful!
was (Author: chetanm):
[patch2|^OAK-2557-2.patch] which uses {{ExternalSort}} to sort the DocumentId
[~egli] [~mreutegg] Can you have a look
[~amitjain] Can you review the usage of ExternalSort as this was also used in
Blob GC. So your feedback would be helpful!
> VersionGC uses way too much memory if there is a large pile of garbage
> --
>
> Key: OAK-2557
> URL: https://issues.apache.org/jira/browse/OAK-2557
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.0.11
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Fix For: 1.0.13, 1.2
>
> Attachments: OAK-2557-2.patch, OAK-2557.patch
>
>
> It has been noticed that on a system where revision-gc
> (VersionGarbageCollector of mongomk) did not run for a few days (due to not
> interfering with some tests/large bulk operations) that there was such a
> large pile of garbage accumulating, that the following code
> {code}
> VersionGarbageCollector.collectDeletedDocuments
> {code}
> in the for loop, creates such a large list of NodeDocuments to delete
> (docIdsToDelete) that it uses up too much memory, causing the JVM's GC to
> constantly spin in Full-GCs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2557) VersionGC uses way too much memory if there is a large pile of garbage
[
https://issues.apache.org/jira/browse/OAK-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2557:
-
Attachment: OAK-2557-2.patch
[patch2|^OAK-2557-2.patch] which uses {{ExternalSort}} to sort the DocumentId
[~egli] [~mreutegg] Can you have a look
[~amitjain] Can you review the usage of ExternalSort as this was also used in
Blob GC. So your feedback would be helpful!
> VersionGC uses way too much memory if there is a large pile of garbage
> --
>
> Key: OAK-2557
> URL: https://issues.apache.org/jira/browse/OAK-2557
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
>Affects Versions: 1.0.11
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Fix For: 1.0.13, 1.2
>
> Attachments: OAK-2557-2.patch, OAK-2557.patch
>
>
> It has been noticed that on a system where revision-gc
> (VersionGarbageCollector of mongomk) did not run for a few days (due to not
> interfering with some tests/large bulk operations) that there was such a
> large pile of garbage accumulating, that the following code
> {code}
> VersionGarbageCollector.collectDeletedDocuments
> {code}
> in the for loop, creates such a large list of NodeDocuments to delete
> (docIdsToDelete) that it uses up too much memory, causing the JVM's GC to
> constantly spin in Full-GCs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2540) Session operations null check
[
https://issues.apache.org/jira/browse/OAK-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-2540.
--
Resolution: Fixed
thanks for the input! applied the patch at with http://svn.apache.org/r1665843
> Session operations null check
> -
>
> Key: OAK-2540
> URL: https://issues.apache.org/jira/browse/OAK-2540
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.1.8
>
> Attachments: OAK-2540.patch
>
>
> Calling a _Session.getNode(null)_ throws an ugly NPE. We should add a few
> null checks and turn those illegal inputs into IAEs.
> For those wondering Jackrabbit doesn't fare better here.
> _Oak_
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.namepath.NamePathMapperImpl.needsFullMapping(NamePathMapperImpl.java:224)
> at
> org.apache.jackrabbit.oak.namepath.NamePathMapperImpl.getOakPath(NamePathMapperImpl.java:80)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPath(SessionContext.java:306)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:325)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getOakPathOrThrow(SessionImpl.java:149)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.access$1(SessionImpl.java:148)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$1.perform(SessionImpl.java:188)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$1.perform(SessionImpl.java:1)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:238)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:139)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getNodeOrNull(SessionImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getNode(SessionImpl.java:315)
> {code}
> _Jackrabbit_
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:93)
> at
> org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:77)
> at
> org.apache.jackrabbit.spi.commons.conversion.DefaultNamePathResolver.getQPath(DefaultNamePathResolver.java:82)
> at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:648)
> at
> org.apache.jackrabbit.core.session.SessionContext.getQPath(SessionContext.java:338)
> at
> org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:185)
> at
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
> at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
> at org.apache.jackrabbit.core.SessionImpl.getNode(SessionImpl.java:)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2603) Failure in one of the batch in VersionGC might lead to orphaned nodes
[
https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2603.
--
Resolution: Fixed
After looking further I realized that having a dedicated
{{NodeDocumentIdComparator}} would be better and it would perform better for
large list sorting so added a comparator and used that to sort in VersionGC in
http://svn.apache.org/r1665835
> Failure in one of the batch in VersionGC might lead to orphaned nodes
> -
>
> Key: OAK-2603
> URL: https://issues.apache.org/jira/browse/OAK-2603
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.1.8, 1.0.13
>
> Attachments: OAK-2603.patch
>
>
> VersionGC logic currently performs deletion of nodes in batches. For GC to
> work properly NodeDocument should always be removed in bottom-up mode i.e.
> parent node should be removed *after* child has been removed
> Currently the GC logic deletes the NodeDocument in undefined order. In such
> mode if one of the batch fails then its possible that parent might have got
> deleted but the child was not deleted.
> Now in next run the child node would not be recognized as a deleted node
> because the commit root would not be found.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2605) Support for additional encodings needed in ReversedLinesFileReader
[ https://issues.apache.org/jira/browse/OAK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356681#comment-14356681 ] Michael Dürig commented on OAK-2605: Follow up issue to clean up this temporary fix. > Support for additional encodings needed in ReversedLinesFileReader > -- > > Key: OAK-2605 > URL: https://issues.apache.org/jira/browse/OAK-2605 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Affects Versions: 1.1.7 > Environment: Windows 2012 R2 Japanese > Windows 2012 R2 Korean > Windows 2012 R2 Simplified Chinese > Windows 2012 R2 Traditional Chinese >Reporter: Leandro Reis >Assignee: Michael Dürig > Fix For: 1.1.8 > > Attachments: OAK-2605.patch > > > I'm working on a product that uses Commons IO via Jackrabbit Oak. In the > process of testing the launch of such product on Japanese Windows 2012 > Server R2, I came across the following exception: > "(java.io.UnsupportedEncodingException: Encoding windows-31j is not supported > yet (feel free to submit a patch))" > windows-31j is the IANA name for Windows code page 932 (Japanese), and is > returned by Charset.defaultCharset(), used in > org.apache.commons.io.input.ReversedLinesFileReader [0]. > A patch for this issue was provided in > https://issues.apache.org/jira/browse/IO-471 . > It also includes changes needed to support Chinese Simplified, Chinese > Traditional and Korean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2606) Remove code duplicated from commons-io
Michael Dürig created OAK-2606:
--
Summary: Remove code duplicated from commons-io
Key: OAK-2606
URL: https://issues.apache.org/jira/browse/OAK-2606
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Michael Dürig
Assignee: Michael Dürig
Priority: Minor
OAK-2605 implements a workaround to IO-471 by duplicating the respective
classes from commons-io with the IO-471 fix applied. We should revert back to
using the classes from commons-io directly once there is a new release.
See {{FIXME}} tags in http://svn.apache.org/r1665833 for where this applies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2605) Support for additional encodings needed in ReversedLinesFileReader
[ https://issues.apache.org/jira/browse/OAK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-2605. Resolution: Fixed Fixed at http://svn.apache.org/r1665833. Thanks [~lreis] for the qualified report, patch and tests. Great work! > Support for additional encodings needed in ReversedLinesFileReader > -- > > Key: OAK-2605 > URL: https://issues.apache.org/jira/browse/OAK-2605 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Affects Versions: 1.1.7 > Environment: Windows 2012 R2 Japanese > Windows 2012 R2 Korean > Windows 2012 R2 Simplified Chinese > Windows 2012 R2 Traditional Chinese >Reporter: Leandro Reis >Assignee: Michael Dürig > Fix For: 1.1.8 > > Attachments: OAK-2605.patch > > > I'm working on a product that uses Commons IO via Jackrabbit Oak. In the > process of testing the launch of such product on Japanese Windows 2012 > Server R2, I came across the following exception: > "(java.io.UnsupportedEncodingException: Encoding windows-31j is not supported > yet (feel free to submit a patch))" > windows-31j is the IANA name for Windows code page 932 (Japanese), and is > returned by Charset.defaultCharset(), used in > org.apache.commons.io.input.ReversedLinesFileReader [0]. > A patch for this issue was provided in > https://issues.apache.org/jira/browse/IO-471 . > It also includes changes needed to support Chinese Simplified, Chinese > Traditional and Korean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2566) PropertyRestriction.isNotNullRestriction does not take "list" into account
[ https://issues.apache.org/jira/browse/OAK-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2566: Component/s: (was: oak-core) core > PropertyRestriction.isNotNullRestriction does not take "list" into account > -- > > Key: OAK-2566 > URL: https://issues.apache.org/jira/browse/OAK-2566 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.1.8, 1.0.13, 1.2 > > > The method PropertyRestriction.isNotNullRestriction does not take the field > "list" into account, so that a condition of the form "x in(1, 2)" is also a > "not null" restriction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1451) Expose index size
[ https://issues.apache.org/jira/browse/OAK-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1451: Fix Version/s: (was: 1.3.1) 1.3.0 > Expose index size > - > > Key: OAK-1451 > URL: https://issues.apache.org/jira/browse/OAK-1451 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Michael Marth >Priority: Minor > Labels: production, resilience > Fix For: 1.3.0 > > > At the moment some MK's disc needs are largely from the indexes. Maybe we can > do something about this, but in the meantime it would be helpful if we could > expose the index sizes (num of indexed nodes) via JMX so that they could be > easily monitored. > This would also be helpful to see at which point an index becomes useless (if > the majority of content nodes are indexed one might as well not have an index) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-662) Reduce boilerplate code in JCR impl methods
[ https://issues.apache.org/jira/browse/OAK-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-662. Resolution: Later Fix Version/s: (was: 1.2) > Reduce boilerplate code in JCR impl methods > --- > > Key: OAK-662 > URL: https://issues.apache.org/jira/browse/OAK-662 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Jukka Zitting >Priority: Minor > > As discussed on oak-dev@, it would be useful to find ways to reduce the > amount of repetitive boilerplate code in the various JCR implementation > methods we have. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2096) Oak-Run explore should work on MongoMK
[ https://issues.apache.org/jira/browse/OAK-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2096. - Resolution: Won't Fix > Oak-Run explore should work on MongoMK > -- > > Key: OAK-2096 > URL: https://issues.apache.org/jira/browse/OAK-2096 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Justin Edelson > > It is IMHO strangely inconsistent that oak-run's console work with both TarMK > and MongoMK but the explorer only works with TarMK. While there are some menu > options in explorer specific to TarMK, those can just be suppressed if > MongoMK is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2096) Oak-Run explore should work on MongoMK
[ https://issues.apache.org/jira/browse/OAK-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2096: Fix Version/s: (was: 1.2) > Oak-Run explore should work on MongoMK > -- > > Key: OAK-2096 > URL: https://issues.apache.org/jira/browse/OAK-2096 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, run >Reporter: Justin Edelson > > It is IMHO strangely inconsistent that oak-run's console work with both TarMK > and MongoMK but the explorer only works with TarMK. While there are some menu > options in explorer specific to TarMK, those can just be suppressed if > MongoMK is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1410) Allow automatic propagation of oak-whiteboard when adding security manager
[ https://issues.apache.org/jira/browse/OAK-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356510#comment-14356510 ] angela commented on OAK-1410: - removing fix version 1.2 > Allow automatic propagation of oak-whiteboard when adding security manager > -- > > Key: OAK-1410 > URL: https://issues.apache.org/jira/browse/OAK-1410 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1410) Allow automatic propagation of oak-whiteboard when adding security manager
[ https://issues.apache.org/jira/browse/OAK-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1410: Fix Version/s: (was: 1.2) > Allow automatic propagation of oak-whiteboard when adding security manager > -- > > Key: OAK-1410 > URL: https://issues.apache.org/jira/browse/OAK-1410 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2603) Failure in one of the batch in VersionGC might lead to orphaned nodes
[ https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356456#comment-14356456 ] Chetan Mehrotra commented on OAK-2603: -- bq. I noticed one minor thing: the debug message mentions ids, but now passes paths. We should either change the message or transform the paths to ids. Ack bq. I was also wondering if the partitioning is necessary because we already do that in the MongoDocumentStore.remove(). The problem is that remove takes a list and not iterator currently. Creating a complete new list post transformation would have doubled the storage cost. So used current approach. This would also be later required for fix done for OAK-2557 > Failure in one of the batch in VersionGC might lead to orphaned nodes > - > > Key: OAK-2603 > URL: https://issues.apache.org/jira/browse/OAK-2603 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.1.8, 1.0.13 > > Attachments: OAK-2603.patch > > > VersionGC logic currently performs deletion of nodes in batches. For GC to > work properly NodeDocument should always be removed in bottom-up mode i.e. > parent node should be removed *after* child has been removed > Currently the GC logic deletes the NodeDocument in undefined order. In such > mode if one of the batch fails then its possible that parent might have got > deleted but the child was not deleted. > Now in next run the child node would not be recognized as a deleted node > because the commit root would not be found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2603) Failure in one of the batch in VersionGC might lead to orphaned nodes
[ https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356453#comment-14356453 ] Marcel Reutegger commented on OAK-2603: --- I like the approach with the PathComparator better. This way we don't have to introduce yet another comparator. I noticed one minor thing: the debug message mentions ids, but now passes paths. We should either change the message or transform the paths to ids. I was also wondering if the partitioning is necessary because we already do that in the MongoDocumentStore.remove(). > Failure in one of the batch in VersionGC might lead to orphaned nodes > - > > Key: OAK-2603 > URL: https://issues.apache.org/jira/browse/OAK-2603 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.1.8, 1.0.13 > > Attachments: OAK-2603.patch > > > VersionGC logic currently performs deletion of nodes in batches. For GC to > work properly NodeDocument should always be removed in bottom-up mode i.e. > parent node should be removed *after* child has been removed > Currently the GC logic deletes the NodeDocument in undefined order. In such > mode if one of the batch fails then its possible that parent might have got > deleted but the child was not deleted. > Now in next run the child node would not be recognized as a deleted node > because the commit root would not be found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2603) Failure in one of the batch in VersionGC might lead to orphaned nodes
[ https://issues.apache.org/jira/browse/OAK-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2603: - Attachment: OAK-2603.patch [patch|^OAK-2603.patch] which # initially collects the paths to be deleted # Sort using PathComparator # Uses a PATH_TO_ID transformation before passing the paths to DocumentStore (which works with ids) for removal [~mreutegg] Can you review. Initially I thought to implement a ID Comparator on line of PathComparator. However was not sure about id's based on long path. It might have still worked because sort first on depth would ensure that parent end up last in the list. > Failure in one of the batch in VersionGC might lead to orphaned nodes > - > > Key: OAK-2603 > URL: https://issues.apache.org/jira/browse/OAK-2603 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.1.8, 1.0.13 > > Attachments: OAK-2603.patch > > > VersionGC logic currently performs deletion of nodes in batches. For GC to > work properly NodeDocument should always be removed in bottom-up mode i.e. > parent node should be removed *after* child has been removed > Currently the GC logic deletes the NodeDocument in undefined order. In such > mode if one of the batch fails then its possible that parent might have got > deleted but the child was not deleted. > Now in next run the child node would not be recognized as a deleted node > because the commit root would not be found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
