[jira] [Updated] (OAK-4927) FileStore compaction should account for multiple valid checkpoints

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated OAK-4927:
-
Summary: FileStore compaction should account for multiple valid checkpoints 
 (was: FileStore compaction logs a misleading warning in case it finds more 
than one checkpoint)

> FileStore compaction should account for multiple valid checkpoints
> --
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
>  Labels: candidate_oak_1_4
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead 
> to multiple checkpoint present in the system. OAK-4043 addressed that in 
> oak-run. However currently the 
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
> warning if more than one checkpoint is found. 
> {noformat}
> 22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4927) FileStore compaction logs a misleading warning in case it finds more than one checkpoint

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567690#comment-15567690
 ] 

Chetan Mehrotra commented on OAK-4927:
--

[~alex.parvulescu] Can you have a look? Also not sure if similar warning is 
logged with segment-tar

> FileStore compaction logs a misleading warning in case it finds more than one 
> checkpoint
> 
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
>  Labels: candidate_oak_1_4
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead 
> to multiple checkpoint present in the system. OAK-4043 addressed that in 
> oak-run. However currently the 
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
> warning if more than one checkpoint is found. 
> {noformat}
> 22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4927) FileStore compaction logs a misleading warning in case it finds more than one checkpoint

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated OAK-4927:
-
Labels: candidate_oak_1_4  (was: )

> FileStore compaction logs a misleading warning in case it finds more than one 
> checkpoint
> 
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
>  Labels: candidate_oak_1_4
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead 
> to multiple checkpoint present in the system. OAK-4043 addressed that in 
> oak-run. However currently the 
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
> warning if more than one checkpoint is found. 
> {noformat}
> 22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4927) FileStore compaction logs a misleading warning in case it finds more than one checkpoint

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated OAK-4927:
-
Affects Version/s: 1.4

> FileStore compaction logs a misleading warning in case it finds more than one 
> checkpoint
> 
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead 
> to multiple checkpoint present in the system. OAK-4043 addressed that in 
> oak-run. However currently the 
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
> warning if more than one checkpoint is found. 
> {noformat}
> 22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4927) FileStore compaction logs a misleading warning in case it finds more than one checkpoint

[Chetan Mehrotra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Mehrotra updated OAK-4927:
-
Assignee: Alex Parvulescu

> FileStore compaction logs a misleading warning in case it finds more than one 
> checkpoint
> 
>
> Key: OAK-4927
> URL: https://issues.apache.org/jira/browse/OAK-4927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.4
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.6
>
>
> With Oak 1.4 we have setup which configure multiple async indexers which lead 
> to multiple checkpoint present in the system. OAK-4043 addressed that in 
> oak-run. However currently the 
> {{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
> warning if more than one checkpoint is found. 
> {noformat}
> 22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
> compaction found 2 checkpoints, you might need to run checkpoint cleanup
> {noformat}
> This warning should be fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4927) FileStore compaction logs a misleading warning in case it finds more than one checkpoint

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created OAK-4927:


 Summary: FileStore compaction logs a misleading warning in case it 
finds more than one checkpoint
 Key: OAK-4927
 URL: https://issues.apache.org/jira/browse/OAK-4927
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: segmentmk
Reporter: Chetan Mehrotra
Priority: Minor
 Fix For: 1.6


With Oak 1.4 we have setup which configure multiple async indexers which lead 
to multiple checkpoint present in the system. OAK-4043 addressed that in 
oak-run. However currently the 
{{org.apache.jackrabbit.oak.plugins.segment.file.FileStore#compact}} logs a 
warning if more than one checkpoint is found. 

{noformat}
22:34:21.797 [main] WARN  o.a.j.o.p.segment.file.FileStore - TarMK GC #0: 
compaction found 2 checkpoints, you might need to run checkpoint cleanup
{noformat}

This warning should be fixed





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-4925) Don't call @Nonnull TypeEditor.getEffective() from constructor

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig resolved OAK-4925.

Resolution: Fixed

Fixed at http://svn.apache.org/viewvc?rev=1764299=rev

> Don't call @Nonnull TypeEditor.getEffective() from constructor
> --
>
> Key: OAK-4925
> URL: https://issues.apache.org/jira/browse/OAK-4925
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 1.5.13
>
>
> {{TypeEditor.getEffective()}} is declared {{@Nonnull}}. However when called 
> from within the constructor and before its underlying field {{effective}} is 
> initialised in actually *does* return {{null}}. The fix would be to avoid 
> calling this method from the constructor. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated OAK-4926:

Summary: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect 
missing segment  (was: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should 
except missing segment)

> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should expect missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method 
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
>  does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the 
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
> statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OAK-4883) Missing BlobGarbageCollection MBean on standby instance

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret reassigned OAK-4883:
---

Assignee: Timothee Maret

> Missing BlobGarbageCollection MBean on standby instance
> ---
>
> Key: OAK-4883
> URL: https://issues.apache.org/jira/browse/OAK-4883
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, segmentmk
>Reporter: Alex Parvulescu
>Assignee: Timothee Maret
>  Labels: gc
> Attachments: OAK-4883.patch
>
>
> The {{BlobGarbageCollection}} MBean is no longer available on a standby 
> instance, this affects non-shared datastore setups (on a shared datastore 
> you'd only need to run blob gc on the primary).
> This change was introduced by OAK-4089 (and backported to 1.4 branch with 
> OAK-4093).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret reassigned OAK-4926:
---

Assignee: Timothee Maret

> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method 
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
>  does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the 
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
> statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment

[Timothee Maret (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565910#comment-15565910
 ] 

Timothee Maret commented on OAK-4926:
-

[~frm] could you look at the patch please ?

> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method 
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
>  does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the 
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
> statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated OAK-4926:

Attachment: OAK-4926.patch

Attaching a svn compatible patch, otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/2a6f4b47074966a895692ef7de764f9902c7adfb.patch

> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method 
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
>  does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the 
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
> statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment

[Timothee Maret (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothee Maret updated OAK-4926:

Flags: Patch

> o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment
> --
>
> Key: OAK-4926
> URL: https://issues.apache.org/jira/browse/OAK-4926
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: Segment Tar 0.0.14
>Reporter: Timothee Maret
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4926.patch
>
>
> Currently the method 
> {{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
>  does invoke
> {code}
> referencedId.getSegment();
> {code}
> in order to read the referenced segment. In case of missing segment, the 
> {{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
> statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4926) o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should except missing segment

[Timothee Maret (JIRA)]

Timothee Maret created OAK-4926:
---

 Summary: o.a.j.o.s.s.c.StandbyClientSyncExecution#isLocal should 
except missing segment
 Key: OAK-4926
 URL: https://issues.apache.org/jira/browse/OAK-4926
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: segment-tar
Affects Versions: Segment Tar 0.0.14
Reporter: Timothee Maret
 Fix For: Segment Tar 0.0.16


Currently the method 
{{org.apache.jackrabbit.oak.segment.standby.client.StandbyClientSyncExecution#isLocal}}
 does invoke
{code}
referencedId.getSegment();
{code}
in order to read the referenced segment. In case of missing segment, the 
{{ReferenceId.getSegment}} does throw a SNFE *and* logs an ERROR level 
statement. The SNFE is needed but not the log statement in this case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4925) Don't call @Nonnull TypeEditor.getEffective() from constructor

[JIRA]

Michael Dürig created OAK-4925:
--

 Summary: Don't call @Nonnull TypeEditor.getEffective() from 
constructor
 Key: OAK-4925
 URL: https://issues.apache.org/jira/browse/OAK-4925
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Michael Dürig
Assignee: Michael Dürig
 Fix For: 1.5.13


{{TypeEditor.getEffective()}} is declared {{@Nonnull}}. However when called 
from within the constructor and before its underlying field {{effective}} is 
initialised in actually *does* return {{null}}. The fix would be to avoid 
calling this method from the constructor. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565820#comment-15565820
 ] 

Stefan Egli commented on OAK-4924:
--

Agreed that EMPTY is used elsewhere too - I believe mostly for tests though - 
where it's used in productive code we should review it I think. But agreed yes, 
EMPTY is a generic issue for CommitContext/prefiltering (too).

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565740#comment-15565740
 ] 

Alex Parvulescu commented on OAK-4924:
--

I quite a lot of code in {{oak-core}} using {{EMTPY}}, what makes this specific 
code path different? I'm open to suggestions on what we can do here, but I'm 
wondering if this will actually help in the big picture.

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OAK-4855) Expose actual listener.toString in consolidated listener mbean

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli resolved OAK-4855.
--
   Resolution: Fixed
Fix Version/s: (was: 1.6)
   1.5.13

done in trunk in http://svn.apache.org/viewvc?rev=1764265=rev

> Expose actual listener.toString in consolidated listener mbean
> --
>
> Key: OAK-4855
> URL: https://issues.apache.org/jira/browse/OAK-4855
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.10
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
> Attachments: OAK-4855.patch
>
>
> With SLING-6056 more listeners (in the form of ResourceChangeListeners) will 
> be mapped 1:1 to either BackgroundObservers or JCR EventListeners. That 
> means, they will also be exposed in the consolidated listeners stats. Without 
> any change though, all that can be seen in that stats is the name of that 
> 'bridge/mapper' listener (ie either JcrResourceListener or 
> OakResourceListener), since currently all that is exposed is 
> {{getClass().toString()}} - and the actual ResourceChangeListener sitting 2 
> steps behind is not visible.
> In JCR-4032 I'm suggesting to introduce a {{getToString()}} to the 
> EventListenerMBean, and once that would be available, this could be exposed 
> in the ConsolidatedListenerMBeanImpl.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565616#comment-15565616
 ] 

Stefan Egli commented on OAK-4924:
--

The problem with {{EMPTY}} is actually that it is read-only - so you can't 
store anything in it ..

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565620#comment-15565620
 ] 

Stefan Egli commented on OAK-4924:
--

or let's say it is meant to be read-only - it's not actually read-only atm

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565598#comment-15565598
 ] 

Alex Parvulescu commented on OAK-4924:
--

so does this cover everything? 
https://github.com/stillalex/jackrabbit-oak/commit/6f88341262ae437a686e57970c58853184369372

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565579#comment-15565579
 ] 

Michael Dürig commented on OAK-4924:


+1

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565578#comment-15565578
 ] 

Alex Parvulescu commented on OAK-4924:
--

if it's just about using EMPTY [0], instead of null, I don't see a problem with 
that.

[0] 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/CommitInfo.java#L45

> avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh
> -
>
> Key: OAK-4924
> URL: https://issues.apache.org/jira/browse/OAK-4924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segmentmk
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
> Fix For: 1.6
>
>
> Currently 
> [SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
>  calls {{contentChanged}} with null as the CommitInfo. This is problematic 
> for prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of 
> changed items in a commit is stored in the CommitContext in the CommitInfo.
> Thus it would be useful to not send null but a CommitInfo that has the 
> equivalent meaning of null but is a new object for each call (so that the 
> ChangeSet can be set).
> [~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4465) Remove the read-only concern from TarRevisions

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565567#comment-15565567
 ] 

Alex Parvulescu commented on OAK-4465:
--

proposed patch at 
https://github.com/stillalex/jackrabbit-oak/commit/f61b005faebc61fed78387404a1e7a119759a2ac
this build on work branch started for OAK-4450. FYI [~mduerig] [~frm].

> Remove the read-only concern from TarRevisions
> --
>
> Key: OAK-4465
> URL: https://issues.apache.org/jira/browse/OAK-4465
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: Segment Tar 0.0.18
>
>
> {{TarRevisions}} shouldn't be concerned with the (non) readability issues. 
> This should be the concern of the store alone. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4907) Collect changes (paths, nts, props..) of a commit in a validator

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565521#comment-15565521
 ] 

Stefan Egli commented on OAK-4907:
--

Note that due to OAK-4924 for the {{contentChanged}} calls coming from 
AsyncIndexUpdater no ChangeSet can be attached to the CommitInfo, thus no 
prefiltering can be done for those (and there are quite a few of those calls 
typically) 

> Collect changes (paths, nts, props..) of a commit in a validator
> 
>
> Key: OAK-4907
> URL: https://issues.apache.org/jira/browse/OAK-4907
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4907.patch, OAK-4907.v2.patch
>
>
> It would be useful to collect a set of changes of a commit (eg in a 
> validator) that could later be used in an Observer for eg prefiltering.
> Such a change collector should collect paths, nodetypes, properties, 
> node-names (and perhaps more at a later stage) of all changes and store the 
> result in the CommitInfo's CommitContext.
> Note that this is a result of 
> [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962]
>  around design in OAK-4796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4924) avoid CommitInfo==null in contentChanged call in SegmentNodeStore.refresh

[Stefan Egli (JIRA)]

Stefan Egli created OAK-4924:


 Summary: avoid CommitInfo==null in contentChanged call in 
SegmentNodeStore.refresh
 Key: OAK-4924
 URL: https://issues.apache.org/jira/browse/OAK-4924
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: segmentmk
Affects Versions: 1.5.12
Reporter: Stefan Egli
 Fix For: 1.6


Currently 
[SegmentNodeStore.refreshHead|https://github.com/apache/jackrabbit-oak/blob/d82f9b21d02a7eaf856f546e778118161d71b760/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeStore.java#L231]
 calls {{contentChanged}} with null as the CommitInfo. This is problematic for 
prefiltering (OAK-4796, OAK-4907 et al) as for that a ChangeSet of changed 
items in a commit is stored in the CommitContext in the CommitInfo.

Thus it would be useful to not send null but a CommitInfo that has the 
equivalent meaning of null but is a new object for each call (so that the 
ChangeSet can be set).

[~mduerig], [~frm], [~alex.parvulescu] wdyt?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4907) Collect changes (paths, nts, props..) of a commit in a validator

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated OAK-4907:
-
Attachment: OAK-4907.v2.patch

[^OAK-4907.v2.patch] containing a few renames but mainly the fix that if 
CommitInfo is {{EMPTY}} then change collection is disabled (as one shouldn't 
store anything in the {{CommitInfo.EMPTY}})

> Collect changes (paths, nts, props..) of a commit in a validator
> 
>
> Key: OAK-4907
> URL: https://issues.apache.org/jira/browse/OAK-4907
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4907.patch, OAK-4907.v2.patch
>
>
> It would be useful to collect a set of changes of a commit (eg in a 
> validator) that could later be used in an Observer for eg prefiltering.
> Such a change collector should collect paths, nodetypes, properties, 
> node-names (and perhaps more at a later stage) of all changes and store the 
> result in the CommitInfo's CommitContext.
> Note that this is a result of 
> [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962]
>  around design in OAK-4796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4348) Cross language search via SMT

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565445#comment-15565445
 ] 

Tommaso Teofili commented on OAK-4348:
--

I've reworked the previous implementation by leveraging Lucene index specific 
API for enhancing the query  ( {{FulltextTermQueryProvider}} ), as it makes 
more sense than working (and adding dependencies) at oak-core (query engine) 
level and such workflow is mainly / only meant for full text queries.
The up to date version of integrating Apache Joshua to Oak (Lucene) is at : 
https://github.com/tteofili/jackrabbit-oak/tree/OAK-4348

> Cross language search via SMT
> -
>
> Key: OAK-4348
> URL: https://issues.apache.org/jira/browse/OAK-4348
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: query
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: 1.6
>
>
> It would be interesting to investigate usage of statistical machine 
> translation toolkits (like Apache Joshua) in order to enable cross language 
> search, so that query can be eventually expanded to search over translated 
> terms too.
> Example: 
> - enable spanish to english translation
> - perform full text search for "hola" 
> - query engine looks for translations for "hola"
> - SMT returns "hello"
> - query engine add an additional (UNION) clause for the translated term
> - the query performed by Oak becomes "hello OR hola"
> - both results for english and spanish terms get returned
> This of course should be configurable.
> Note that the integration may happen also via Apache Tika which provides a 
> Translator API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4450) Properly split the FileStore into read-only and r/w variants

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565351#comment-15565351
 ] 

Alex Parvulescu commented on OAK-4450:
--

WIP at 
https://github.com/stillalex/jackrabbit-oak/commit/148296b1ac6f4a96ae24cff60c3116d774052664
[~mduerig], [~frm] feedback appreciated!

> Properly split the FileStore into read-only and r/w variants 
> -
>
> Key: OAK-4450
> URL: https://issues.apache.org/jira/browse/OAK-4450
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: technical_debt
> Fix For: Segment Tar 0.0.18
>
>
> The {{ReadOnlyFileStore}} class currently simply overrides the {{FileStore}} 
> class replacing all mutator methods with a trivial implementation. This 
> approach however leaks into its ancestor as the read only store needs to pass 
> a flag to the constructor of its super class so some fields can be 
> instantiated properly for the read only case. 
> We should clean this up to properly separate the read only and the r/w store. 
> Most likely we should factor the commonalities into a common, abstract base 
> class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4923) Improve segment deserialization performance

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari updated OAK-4923:

Attachment: OAK-4923-02.patch
OAK-4923-01.patch

In the first version of the attached patch, I added two LRU caches shared by 
every segment. Previously loaded data is cached by segment ID. The second 
version of the patch caches the read data per segment, exploiting the fact that 
only used segments are supposed to be retained in memory. In my local 
benchmarks, the first version performs better than the second.

These patches are only proof of concepts, they are not finished by any means. 
[~mduerig], what do you think?

> Improve segment deserialization performance
> ---
>
> Key: OAK-4923
> URL: https://issues.apache.org/jira/browse/OAK-4923
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Attachments: OAK-4923-01.patch, OAK-4923-02.patch
>
>
> The methods {{readReferencedSegments}} and {{readRecordNumberOffsets}} in 
> {{Segment}} compute the returned data every time they are called. While this 
> is a very clean implementation, this might force unexpected I/O operations, 
> since the "buffer" the data is read from usually is a memory-mapped file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4923) Improve segment deserialization performance

[Francesco Mari (JIRA)]

Francesco Mari created OAK-4923:
---

 Summary: Improve segment deserialization performance
 Key: OAK-4923
 URL: https://issues.apache.org/jira/browse/OAK-4923
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: segment-tar
Reporter: Francesco Mari
Assignee: Francesco Mari


The methods {{readReferencedSegments}} and {{readRecordNumberOffsets}} in 
{{Segment}} compute the returned data every time they are called. While this is 
a very clean implementation, this might force unexpected I/O operations, since 
the "buffer" the data is read from usually is a memory-mapped file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OAK-4922) Implement number of facets retrieved in query configurable for LucenePropertyIndex

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili reassigned OAK-4922:


Assignee: Tommaso Teofili

> Implement number of facets retrieved in query configurable for 
> LucenePropertyIndex
> --
>
> Key: OAK-4922
> URL: https://issues.apache.org/jira/browse/OAK-4922
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: lucene
>Affects Versions: 1.4.6
>Reporter: Miroslav Smiljanic
>Assignee: Tommaso Teofili
>
> Currently umber of facts retrieved is 10 and it would be nice to have that 
> value configurable.
> https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.4.6/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1607



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4922) Implement number of facets retrieved in query configurable for LucenePropertyIndex

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated OAK-4922:
-
Description: 
Currently number of facts retrieved is 10 and it would be nice to have that 
value configurable.
https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.4.6/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1607


  was:
Currently umber of facts retrieved is 10 and it would be nice to have that 
value configurable.
https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.4.6/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1607



> Implement number of facets retrieved in query configurable for 
> LucenePropertyIndex
> --
>
> Key: OAK-4922
> URL: https://issues.apache.org/jira/browse/OAK-4922
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: lucene
>Affects Versions: 1.4.6
>Reporter: Miroslav Smiljanic
>Assignee: Tommaso Teofili
>
> Currently number of facts retrieved is 10 and it would be nice to have that 
> value configurable.
> https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.4.6/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1607



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4796) filter events before adding to ChangeProcessor's queue

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565121#comment-15565121
 ] 

Stefan Egli commented on OAK-4796:
--

[~chetanm], [~mreutegg], [~mduerig], finished up those 3 subtasks and would 
commit them, but if you'd like to have yet another look, you're welcome to do 
so. I'll wait with commiting for another day or two.

> filter events before adding to ChangeProcessor's queue
> --
>
> Key: OAK-4796
> URL: https://issues.apache.org/jira/browse/OAK-4796
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.9
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>  Labels: observation
> Fix For: 1.6
>
> Attachments: OAK-4796.changeSet.patch, OAK-4796.patch
>
>
> Currently the 
> [ChangeProcessor.contentChanged|https://github.com/apache/jackrabbit-oak/blob/f4f4e01dd8f708801883260481d37fdcd5868deb/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L335]
>  is in charge of doing the event diffing and filtering and does so in a 
> pooled Thread, ie asynchronously, at a later stage independent from the 
> commit. This has the advantage that the commit is fast, but has the following 
> potentially negative effects:
> # events (in the form of ContentChange Objects) occupy a slot of the queue 
> even if the listener is not interested in it - any commit lands on any 
> listener's queue. This reduces the capacity of the queue for 'actual' events 
> to be delivered. It therefore increases the risk that the queue fills - and 
> when full has various consequences such as loosing the CommitInfo etc.
> # each event==ContentChange later on must be evaluated, and for that a diff 
> must be calculated. Depending on runtime behavior that diff might be 
> expensive if no longer in the cache (documentMk specifically).
> As an improvement, this diffing+filtering could be done at an earlier stage 
> already, nearer to the commit, and in case the filter would ignore the event, 
> it would not have to be put into the queue at all, thus avoiding occupying a 
> slot and later potentially slower diffing.
> The suggestion is to implement this via the following algorithm:
> * During the commit, in a {{Validator}} the listener's filters are evaluated 
> - in an as-efficient-as-possible manner (Reason for doing it in a Validator 
> is that this doesn't add overhead as oak already goes through all changes for 
> other Validators). As a result a _list of potentially affected observers_ is 
> added to the {{CommitInfo}} (false positives are fine).
> ** Note that the above adds cost to the commit and must therefore be 
> carefully done and measured
> ** One potential measure could be to only do filtering when listener's queues 
> are larger than a certain threshold (eg 10)
> * The ChangeProcessor in {{contentChanged}} (in the one created in 
> [createObserver|https://github.com/apache/jackrabbit-oak/blob/f4f4e01dd8f708801883260481d37fdcd5868deb/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L224])
>  then checks the new commitInfo's _potentially affected observers_ list and 
> if it's not in the list, adds a {{NOOP}} token at the end of the queue. If 
> there's already a NOOP there, the two are collapsed (this way when a filter 
> is not affected it would have a NOOP at the end of the queue). If later on a 
> no-NOOP item is added, the NOOP's {{root}} is used as the {{previousRoot}} 
> for the newly added {{ContentChange}} obj.
> ** To achieve that, the ContentChange obj is extended to not only have the 
> "to" {{root}} pointer, but also the "from" {{previousRoot}} pointer which 
> currently is implicitly maintained.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4908) Best-effort prefiltering in ChangeProcessor based on ChangeSet

[Stefan Egli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Egli updated OAK-4908:
-
Attachment: OAK-4908.patch

Attaching [^OAK-4908.patch] which incorporates mentioned feedback from Chetan 
and introduces
* Prefilter.excludeCommits which is implemented by FilterProvider: this method 
is another type of filtering and not compatible with the EventFilter, thus a 
new interface
* PrefilterImpl which is the default implementation
* ObservationManagerImpl composes a PrefilterImpl
* ChangeProcessor connects the dots between Prefilter and BackgroundObserver's 
isExcluded
* ChangeProcessor also has a {{TESTMODE}} which is enabled by default at the 
moment: the idea is that prefiltering can be set in this testmode in which it 
will not actually do prefiltering but actually filter-validation: it checks at 
the time of the onEvent call if prefiltering _would have correctly prefiltered_

> Best-effort prefiltering in ChangeProcessor based on ChangeSet
> --
>
> Key: OAK-4908
> URL: https://issues.apache.org/jira/browse/OAK-4908
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core, jcr
>Affects Versions: 1.5.11
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6
>
> Attachments: OAK-4908.patch
>
>
> This is a subtask as a result of 
> [discussions|https://issues.apache.org/jira/browse/OAK-4796?focusedCommentId=15550962=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15550962]
>  around design in OAK-4796:
> Based on the ChangeSet provided with OAK-4907 in the CommitContext, the 
> ChangeProcessor should do a best-effort prefiltering of commits before they 
> get added to the (BackgroundObserver's) queue.
> This consists of the following parts:
> * -the support for optionally excluding commits from being added to the queue 
> in the BackgroundObserver- EDIT: factored that out into OAK-4916
> * -the BackgroundObserver signaling downstream Observers that a change should 
> be excluded via a {{NOOP_CHANGE}} CommitInfo- EDIT: factored that out into 
> OAK-4916
> * the ChangeProcessor using OAK-4907's ChangeSet of the CommitContext for 
> best-effort prefiltering - and handling the {{NOOP_CHANGED}} CommitInfo 
> introduced in OAK-4916



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OAK-4922) Implement number of facets retrieved in query configurable for LucenePropertyIndex

[Miroslav Smiljanic (JIRA)]

Miroslav Smiljanic created OAK-4922:
---

 Summary: Implement number of facets retrieved in query 
configurable for LucenePropertyIndex
 Key: OAK-4922
 URL: https://issues.apache.org/jira/browse/OAK-4922
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: lucene
Affects Versions: 1.4.6
Reporter: Miroslav Smiljanic


Currently umber of facts retrieved is 10 and it would be nice to have that 
value configurable.
https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.4.6/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1607




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4902) Blob GC completion time should be logged in millis

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4902:
--
Fix Version/s: (was: 1.5.12)
   1.6

> Blob GC completion time should be logged in millis
> --
>
> Key: OAK-4902
> URL: https://issues.apache.org/jira/browse/OAK-4902
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.6
>
>
> MarkSweepGarbageCollector logs the completion time with changing units 
> depending on the time taken - ms, s, min, h etc. This makes it difficult to 
> write scripts to grep the completion time. So, additionally the completion 
> time should also log in milliseconds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4868) Update SegmentS3DataStoreBlobGCTest in oak-it once oak-segment-tar 0.0.14 released

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4868:
--
Fix Version/s: (was: 1.5.12)
   1.6

> Update SegmentS3DataStoreBlobGCTest in oak-it once oak-segment-tar 0.0.14 
> released
> --
>
> Key: OAK-4868
> URL: https://issues.apache.org/jira/browse/OAK-4868
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.6
>
>
> SegmentS3DataStoreBlobGCIT in oak-it needs to be updated with changes similar 
> to done for OAK-4848.
> This would require oak-segment-tar updated to 0.0.14 once released.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4919) Better feedback from method invocations on RevisionGCMBean

[Alex Parvulescu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564992#comment-15564992
 ] 

Alex Parvulescu commented on OAK-4919:
--

looks good

> Better feedback from method invocations on RevisionGCMBean
> --
>
> Key: OAK-4919
> URL: https://issues.apache.org/jira/browse/OAK-4919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: monitoring
> Fix For: 1.5.13
>
>
> The methods to invoke and cancel revision gc return void. This is by design 
> as those calls are asynchronous. The idea is that 
> {{RevisionGC.getRevisionGCStatus()}} would return the current status of an 
> ongoing gc operation. However, currently that method only returns the status 
> of the asynchronous task that was fired off. It should instead be able to 
> convey back the real status of the underlying operation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4906) Support relative property based query by transforming the path

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564980#comment-15564980
 ] 

Julian Sedding commented on OAK-4906:
-

IMHO it would make sense to add:

3b. If {{indexNodeName=true}} add constraint for {{NAME() = 'jcr:content'}}

WDYT?

> Support relative property based query by transforming the path
> --
>
> Key: OAK-4906
> URL: https://issues.apache.org/jira/browse/OAK-4906
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6
>
>
> PropertyIndex supports query like below
> {noformat}
> /jcr:root//*[jcr:content/@keywords]
> {noformat}
> For such query _keywords_ property is indexed and the as part of Cursor 
> returned for the query the path is transformed to return the parent path if 
> the parent node is _jcr:content_
> Currently LucenePropertyIndex supports indexing relative properties wrt base 
> node like {{jcr:content/metadata/status}}. Here it would index the relative 
> property by refererring to its relative name. 
> To simplify switch to LucenePropertyIndex (as part of hybrid index support) 
> LucenePropertyIndex should also support for such queries where property index 
> definition only specifies indexing _keywords_ but the query is using a 
> relative property. So LucenePropertyIndex should
> # First check if it has a property definition for _jcr:content/keywords_
> # If not check if the indexingRule is for nt:base
> # If yes check if it has property definition for _keywords_
> # If yes then use the index to evaluate the query and return transformed 
> result
> LucenePropertyIndex already do such transformations for fulltext constraints. 
> With this we extend that support for property restrictions also



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4919) Better feedback from method invocations on RevisionGCMBean

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564926#comment-15564926
 ] 

Michael Dürig commented on OAK-4919:


Initial proposal: 
https://github.com/mduerig/jackrabbit-oak/commit/6def044ebe798f1fcaf443909624baadbd35d8ed.
 (This is the latest commit of 
https://github.com/mduerig/jackrabbit-oak/commits/OAK-4919, which also includes 
the pending changes for OAK-4617)

The idea is that you can pass a supplier for a status message to 
{{RevisionGC}}, which is called by the latter whenever its status is queried. 
The methods for starting and cancelling a revision gc just fire of a respective 
background operation (an instance of {{ManagmentOperation}}). Their return 
value indicate whether firing the background operation succeeded or failed 
(e.g. because gc is running already). The status of the background operation 
itself would need to be queried through {{RevisionGC.getRevisionGCStatus()}}.

[~alex.parvulescu], WDYT?
[~mreutegg], please provide feedback wrt. the document node store. 

> Better feedback from method invocations on RevisionGCMBean
> --
>
> Key: OAK-4919
> URL: https://issues.apache.org/jira/browse/OAK-4919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: monitoring
> Fix For: 1.5.13
>
>
> The methods to invoke and cancel revision gc return void. This is by design 
> as those calls are asynchronous. The idea is that 
> {{RevisionGC.getRevisionGCStatus()}} would return the current status of an 
> ongoing gc operation. However, currently that method only returns the status 
> of the asynchronous task that was fired off. It should instead be able to 
> convey back the real status of the underlying operation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564894#comment-15564894
 ] 

Michael Dürig commented on OAK-4921:


Ignoring the test for now until we could update the downstream dependencies. 
See http://svn.apache.org/viewvc?rev=1764212=rev

[~edivad], this fixes the build again. 

> SegmentS3DataStoreStatsTest failing
> ---
>
> Key: OAK-4921
> URL: https://issues.apache.org/jira/browse/OAK-4921
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: it
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: regression, test-failure
> Fix For: 1.5.13
>
>
> The tests are currently failing with 
> {noformat}
> ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
>   at 
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
>   at 
> 

[jira] [Updated] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-4921:
---
Component/s: it

> SegmentS3DataStoreStatsTest failing
> ---
>
> Key: OAK-4921
> URL: https://issues.apache.org/jira/browse/OAK-4921
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: it
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: regression, test-failure
> Fix For: 1.5.13
>
>
> The tests are currently failing with 
> {noformat}
> ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
>   at 
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.activate(SegmentNodeStoreService.java:304)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Updated] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-4921:
---
Fix Version/s: 1.5.13

> SegmentS3DataStoreStatsTest failing
> ---
>
> Key: OAK-4921
> URL: https://issues.apache.org/jira/browse/OAK-4921
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: regression, test-failure
> Fix For: 1.5.13
>
>
> The tests are currently failing with 
> {noformat}
> ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
>   at 
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.activate(SegmentNodeStoreService.java:304)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   

[jira] [Commented] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564806#comment-15564806
 ] 

Michael Dürig commented on OAK-4921:


The test requires updating the dependencies. 

> SegmentS3DataStoreStatsTest failing
> ---
>
> Key: OAK-4921
> URL: https://issues.apache.org/jira/browse/OAK-4921
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: regression, test-failure
>
> The tests are currently failing with 
> {noformat}
> ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
>   at 
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.activate(SegmentNodeStoreService.java:304)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Commented] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564746#comment-15564746
 ] 

Michael Dürig commented on OAK-4921:


[~edivad] FYI, this is probably blocking the release. I'm looking into it. 

> SegmentS3DataStoreStatsTest failing
> ---
>
> Key: OAK-4921
> URL: https://issues.apache.org/jira/browse/OAK-4921
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: regression, test-failure
>
> The tests are currently failing with 
> {noformat}
> ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
>   at 
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at 
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.activate(SegmentNodeStoreService.java:304)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Created] (OAK-4921) SegmentS3DataStoreStatsTest failing

[JIRA]

Michael Dürig created OAK-4921:
--

 Summary: SegmentS3DataStoreStatsTest failing
 Key: OAK-4921
 URL: https://issues.apache.org/jira/browse/OAK-4921
 Project: Jackrabbit Oak
  Issue Type: Bug
Reporter: Michael Dürig
Assignee: Michael Dürig


The tests are currently failing with 

{noformat}
ava.lang.RuntimeException: Unable to invoke method 'activate' for class 
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService

at 
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:262)
at 
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:86)
at 
org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:162)
at 
org.apache.sling.testing.mock.osgi.MockOsgi.activate(MockOsgi.java:173)
at 
org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.registerInjectActivateService(OsgiContextImpl.java:142)
at 
org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.registerSegmentNodeStoreService(SegmentS3DataStoreStatsTest.java:113)
at 
org.apache.jackrabbit.oak.segment.SegmentS3DataStoreStatsTest.testUseS3BlobStore(SegmentS3DataStoreStatsTest.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:43)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:239)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NoSuchMethodError: 
org.apache.jackrabbit.oak.spi.state.RevisionGC.(Ljava/lang/Runnable;Ljava/util/concurrent/Executor;)V
at 
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerSegmentStore(SegmentNodeStoreService.java:471)
at 
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.registerNodeStore(SegmentNodeStoreService.java:339)
at 
org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.activate(SegmentNodeStoreService.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:253)
... 38 more
{noformat}

Most likely our changes in 

[jira] [Assigned] (OAK-4919) Better feedback from method invocations on RevisionGCMBean

[JIRA]

 [ 
https://issues.apache.org/jira/browse/OAK-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig reassigned OAK-4919:
--

Assignee: Michael Dürig

> Better feedback from method invocations on RevisionGCMBean
> --
>
> Key: OAK-4919
> URL: https://issues.apache.org/jira/browse/OAK-4919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>  Labels: monitoring
> Fix For: 1.5.13
>
>
> The methods to invoke and cancel revision gc return void. This is by design 
> as those calls are asynchronous. The idea is that 
> {{RevisionGC.getRevisionGCStatus()}} would return the current status of an 
> ongoing gc operation. However, currently that method only returns the status 
> of the asynchronous task that was fired off. It should instead be able to 
> convey back the real status of the underlying operation. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OAK-4920) Performance: DefaultSyncHandler.listIdentities() search too broad, triggers traversal warning

[Alexander Klimetschek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated OAK-4920:
---
Description: 
DefaultSyncHandler.listIdentities() collects users by [searching for all nodes 
under 
/home|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L143]
 – the xpath query executed is

{noformat}
/jcr:root/home//element(*)[@jcr:primaryType]
{noformat}

With a few hundred users this easily gives an oak index traversal warning:
{noformat}
org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed 1000 
nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] 
as a where [jcr:primaryType] is not null and isdescendantnode(a, '/home') /* 
xpath: /jcr:root/home//element(*)[@jcr:primaryType] */, path=/home//*, 
property=[jcr:primaryType=[is not null]]); consider creating an index or 
changing the query
{noformat}

A few lines later [it actually 
reduces|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L151]
 the result to authorizables which have a {{rep:externalId}}. Since OAK-4301 
there is an oak index for {{rep:externalId}}, so the query can be optimized by 
searching for anything with {{rep:externalId}} instead:
{code:java}
userManager.findAuthorizables("rep:externalId", null);
{code}


  was:
DefaultSyncHandler.listIdentities() collects users by [searching for all nodes 
under 
/home|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L143]
 – the xpath query executed is 
{{/jcr:root/home//element(\*)\[@jcr:primaryType]}}. With a few hundred users 
this easily gives an oak index traversal warning:
{noformat}
org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed 1000 
nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] 
as a where [jcr:primaryType] is not null and isdescendantnode(a, '/home') /* 
xpath: /jcr:root/home//element(*)[@jcr:primaryType] */, path=/home//*, 
property=[jcr:primaryType=[is not null]]); consider creating an index or 
changing the query
{noformat}

However, [later it 
reduces|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L151]
 the result to authorizables which have a {{rep:externalId}}.

Since OAK-4301 there is an oak index for {{rep:externalId}}, so the query can 
be optimized by searching for anything with {{rep:externalId}} instead:
{code:java}
userManager.findAuthorizables("rep:externalId", null);
{code}



> Performance: DefaultSyncHandler.listIdentities() search too broad, triggers 
> traversal warning
> -
>
> Key: OAK-4920
> URL: https://issues.apache.org/jira/browse/OAK-4920
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: auth-external
>Affects Versions: 1.4.8, 1.5.11
>Reporter: Alexander Klimetschek
>
> DefaultSyncHandler.listIdentities() collects users by [searching for all 
> nodes under 
> /home|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L143]
>  – the xpath query executed is
> {noformat}
> /jcr:root/home//element(*)[@jcr:primaryType]
> {noformat}
> With a few hundred users this easily gives an oak index traversal warning:
> {noformat}
> org.apache.jackrabbit.oak.spi.query.Cursors$TraversingCursor Traversed 1000 
> nodes with filter Filter(query=select [jcr:path], [jcr:score], * from 
> [nt:base] as a where [jcr:primaryType] is not null and isdescendantnode(a, 
> '/home') /* xpath: /jcr:root/home//element(*)[@jcr:primaryType] */, 
> path=/home//*, property=[jcr:primaryType=[is not null]]); consider creating 
> an index or changing the query
> {noformat}
> A few lines later [it actually 
> reduces|https://github.com/apache/jackrabbit-oak/blob/b3e62e3467bf6433b5a419c2f371331f33e57820/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncHandler.java#L151]
>  the result to authorizables which have a {{rep:externalId}}. Since OAK-4301 
> there is an oak index for {{rep:externalId}}, so the query can be optimized 
> by searching for anything