Re: modify aggregated privilege

[Angela Schreiber]

hi marco

no, that's not possible.

kind regards
angela

On 23/03/17 17:47, "Marco Piovesana"  wrote:

>Hi all,
>I have defined a custom aggregated privilege defined like this:
>
>PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
>session.getWorkspace()).getPrivilegeManager();
>Privilege privilege =
>privilegeManager.registerPrivilege("custom:myAggregated",
>false, new String[]{Privilege.JCR_READ,
>Privilege.JCR_READ_ACCESS_CONTROL});
>
>now i need to modify its definition (change the list of
>"declaredAggregateNames") but I can't find a way to do it. Is it possible
>to unregister it or modify its definition after it has been registered?
>
>Marco.

Re: Documenting enhancements done in Oak 1.6

[Angela Schreiber]

and maybe i have to add: the things i have been working on should already
be included in the documentation because i try to do that before i resolve
the issue. 

so my comment refers to what i would expect to be linked on the main...
not sure how your suggestion below would be covered by stuff that is
already documented...

angela

On 23/03/17 15:40, "Angela Schreiber"  wrote:

>hi chetan
>
>wouldn't it make more sense to generated list directly from JIRA? after
>all that's exactly i would do to make sure i have a comprehensive list of
>improvements and new features i was working on between oak 1.4 and 1.6.
>
>kind regards
>angela
>
>
>On 23/03/17 15:15, "Chetan Mehrotra"  wrote:
>
>>Hi Team,
>>
>>As part of OAK-5976 I am trying to collect topics around various
>>enhancements done in Oak 1.6 release which we should document and make
>>end user aware of them and take benefit of.
>>
>>For now I have covered various topics in Indexing, Document NodeStore
>>new features, Observation etc.
>>
>>Kindly create subtask under this for any new feature/enhancement which
>>you can remember.
>>
>>Once this is done I would like to link to those new changes from the
>>main site page!
>>
>>Chetan Mehrotra
>

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Alex Parvulescu]

Hi,

thanks for the feedback!
I quickly tested the proposed solution (on both emails :) to disable
mmapping for that check and it seems to very nicely alleviate the problem.

Bonus points: oak-segment-tar doesn't seem affected by this (all commands
impls move to the segment-tar module), except a single command that is
related to datastore consistency: 'datastorecheck'.

I'll followup with an oak issue to disable mmaps for the version check.

thanks,
alex




On Thu, Mar 23, 2017 at 4:28 PM, Francesco Mari 
wrote:

> Hi,
>
> 2017-03-23 16:13 GMT+01:00 Alex Parvulescu :
> > Hi,
> >
> > To add what I have found so far. This seems related to OAK-4274, but I
> > think there might be a twist in there somewhere.
> > I'm pretty sure that this method is the one introducing the extra full
> > mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail
> [0].
> > Disabling this method takes the 2x mapping away completely.
>
> I think your analysis matches with the 2x increase in memory mappings.
> It might be that the memory mappings created while opening the
> FileStore in read-only mode are never garbage collected, even if the
> FileStore is correctly closed when checkFileStoreVersionOrFail()
> returns. To avoid this, we might want to open the FileStore in
> checkFileStoreVersionOrFail() with memory mapping disabled.
>
> > The reason I'm saying it is relate to OAK-4274 is because I looked at a
> > heap dump to verify what is keeping the references to the readonly store
> > and there are no live ones, the refs should be GC'ed, but for some reason
> > they are not.
> >
> > I'm still poking around, did not create an oak issue yet. Still pending
> is
> > to verify if this affects other areas than oak-run.
> >
> > Feedback is more than welcome!
> >
> > best,
> > alex
> >
> > [0]
> > https://github.com/apache/jackrabbit-oak/blob/1.6/oak-
> run/src/main/java/org/apache/jackrabbit/oak/plugins/
> segment/FileStoreHelper.java#L209
>

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Francesco Mari]

Hi,

2017-03-23 16:13 GMT+01:00 Alex Parvulescu :
> Hi,
>
> To add what I have found so far. This seems related to OAK-4274, but I
> think there might be a twist in there somewhere.
> I'm pretty sure that this method is the one introducing the extra full
> mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail [0].
> Disabling this method takes the 2x mapping away completely.

I think your analysis matches with the 2x increase in memory mappings.
It might be that the memory mappings created while opening the
FileStore in read-only mode are never garbage collected, even if the
FileStore is correctly closed when checkFileStoreVersionOrFail()
returns. To avoid this, we might want to open the FileStore in
checkFileStoreVersionOrFail() with memory mapping disabled.

> The reason I'm saying it is relate to OAK-4274 is because I looked at a
> heap dump to verify what is keeping the references to the readonly store
> and there are no live ones, the refs should be GC'ed, but for some reason
> they are not.
>
> I'm still poking around, did not create an oak issue yet. Still pending is
> to verify if this affects other areas than oak-run.
>
> Feedback is more than welcome!
>
> best,
> alex
>
> [0]
> https://github.com/apache/jackrabbit-oak/blob/1.6/oak-run/src/main/java/org/apache/jackrabbit/oak/plugins/segment/FileStoreHelper.java#L209

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Michael Dürig]

Hi,


I'm pretty sure that this method is the one introducing the extra
full mapping of the repository:
FileStoreHelper.checkFileStoreVersionOrFail


We should probably run this check with memory mapping disabled anyway. 
Nothing to gain here but probably this would fix the double mapping and 
sideline OAK-4274, which effectively is 
http://bugs.java.com/view_bug.do?bug_id=4724038.


Michael


On 23.03.17 16:13, Alex Parvulescu wrote:

Hi,

To add what I have found so far. This seems related to OAK-4274, but
I think there might be a twist in there somewhere. I'm pretty sure
that this method is the one introducing the extra full mapping of the
repository: FileStoreHelper.checkFileStoreVersionOrFail [0].
Disabling this method takes the 2x mapping away completely.

The reason I'm saying it is relate to OAK-4274 is because I looked at
a heap dump to verify what is keeping the references to the readonly
store and there are no live ones, the refs should be GC'ed, but for
some reason they are not.

I'm still poking around, did not create an oak issue yet. Still
pending is to verify if this affects other areas than oak-run.

Feedback is more than welcome!

best, alex

[0]
https://github.com/apache/jackrabbit-oak/blob/1.6/oak-run/src/main/java/org/apache/jackrabbit/oak/plugins/segment/FileStoreHelper.java#L209







On Thu, Mar 23, 2017 at 12:10 PM, Ian Boston  wrote:


Hi, Based on the page fault behaviour, I think the areas mapped and
reported by pmap are being actively accessed by the JVM. The number
of page faults for Oak 1.4.11 is well over 2x the number of page
faults for Oak 1.0.29 on the same VM, with the same DB when
performing an oak-run offline compaction. This is on the same VM
with the same repository in the same state. The Tar files are not
the same, but 1 copy of the tar files is 32GB in both instances,
1.4.11 maps 64GB as mentioned before.

I dont know if its the behaviour seen in OAK-4274. I have seen
similar in the past. I was not confident that a GC cycle did unmap,
but it would be logical. Best Regards Ian

On 23 March 2017 at 09:07, Francesco Mari
 wrote:


You might be hitting OAK-4274, which I discovered quite some time
ago. I'm not aware of a way to resolve this issue at the moment.

2017-03-22 16:47 GMT+01:00 Alex Parvulescu
:

Hi,

To give more background this came about during an investigation
into a

slow

offline compaction but it may affect any running FileStore as
well (to

be

verified). I don't think it's related to oak-run itself, but
more with the way we

map

files, and so far it looks like a bug (there is no reasonable

explanation

for mapping each tar file twice).

Took a quick look at the TarReader but there are not many
changes in

this

area 1.0 vs. 1.4 branches. If no one has better ideas, I'll
create an oak issue and investigate

this a

bit further.

thanks, alex


On Wed, Mar 22, 2017 at 4:28 PM, Ian Boston 
wrote:


Hi, I am looking at Oak-run and I see 2x the mapped memory
between 1.0.29

and

1.4.10. It looks like in 1.0.29 each segment file is mapped
into

memory

once, but in 1.4.10 its mapped into memory 2x.

Is this expected ?

Its not great for page faults. Best Regards Ian

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Alex Parvulescu]

Hi,

To add what I have found so far. This seems related to OAK-4274, but I
think there might be a twist in there somewhere.
I'm pretty sure that this method is the one introducing the extra full
mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail [0].
Disabling this method takes the 2x mapping away completely.

The reason I'm saying it is relate to OAK-4274 is because I looked at a
heap dump to verify what is keeping the references to the readonly store
and there are no live ones, the refs should be GC'ed, but for some reason
they are not.

I'm still poking around, did not create an oak issue yet. Still pending is
to verify if this affects other areas than oak-run.

Feedback is more than welcome!

best,
alex

[0]
https://github.com/apache/jackrabbit-oak/blob/1.6/oak-run/src/main/java/org/apache/jackrabbit/oak/plugins/segment/FileStoreHelper.java#L209






On Thu, Mar 23, 2017 at 12:10 PM, Ian Boston  wrote:

> Hi,
> Based on the page fault behaviour, I think the areas mapped and reported by
> pmap are being actively accessed by the JVM. The number of page faults for
> Oak 1.4.11 is well over 2x the number of page faults for Oak 1.0.29 on the
> same VM, with the same DB when performing an oak-run offline compaction.
> This is on the same VM with the same repository in the same state. The Tar
> files are not the same, but 1 copy of the tar files is 32GB in both
> instances, 1.4.11 maps 64GB as mentioned before.
>
> I dont know if its the behaviour seen in OAK-4274. I have seen similar in
> the past. I was not confident that a GC cycle did unmap, but it would be
> logical.
> Best Regards
> Ian
>
> On 23 March 2017 at 09:07, Francesco Mari 
> wrote:
>
> > You might be hitting OAK-4274, which I discovered quite some time ago.
> > I'm not aware of a way to resolve this issue at the moment.
> >
> > 2017-03-22 16:47 GMT+01:00 Alex Parvulescu :
> > > Hi,
> > >
> > > To give more background this came about during an investigation into a
> > slow
> > > offline compaction but it may affect any running FileStore as well (to
> be
> > > verified).
> > > I don't think it's related to oak-run itself, but more with the way we
> > map
> > > files, and so far it looks like a bug (there is no reasonable
> explanation
> > > for mapping each tar file twice).
> > >
> > > Took a quick look at the TarReader but there are not many changes in
> this
> > > area 1.0 vs. 1.4 branches.
> > > If no one has better ideas, I'll create an oak issue and investigate
> > this a
> > > bit further.
> > >
> > > thanks,
> > > alex
> > >
> > >
> > > On Wed, Mar 22, 2017 at 4:28 PM, Ian Boston  wrote:
> > >
> > >> Hi,
> > >> I am looking at Oak-run and I see 2x the mapped memory between 1.0.29
> > and
> > >> 1.4.10. It looks like in 1.0.29 each segment file is mapped into
> memory
> > >> once, but in 1.4.10 its mapped into memory 2x.
> > >>
> > >> Is this expected ?
> > >>
> > >> Its not great for page faults.
> > >> Best Regards
> > >> Ian
> > >>
> >
>

Re: Timeout on Oak Queries ?

[Ian Boston]

I have created https://issues.apache.org/jira/browse/OAK-5978 to track.
Best Regards
Ian

On 23 March 2017 at 14:03, Davide Giannella  wrote:

> On 23/03/2017 11:12, Ian Boston wrote:
> > Hi,
> > Is it possible to configure a maximum execution time for Oak queries ?
> >
> > Other "database" systems often monitor the time a query is taking and
> kill
> > if if it exceeds a time limit to avoid long running queries causing
> outages.
> >
> >
>
> I'm aware of "timeouts" on node reads but not on time. So we cancel a
> query that iterated over a certain amount of nodes or as of 1.6 may hit
> the traversal index https://issues.apache.org/jira/browse/OAK-4888.
>
> Not aware on time constraints. I think though it will be a good feature
> to add if not there.
>
> Davide
>
>
>

Re: Documenting enhancements done in Oak 1.6

[Matt Ryan]

Hi Chetan,

I created OAK-5977 [0] for S3DataStore changes as a subtask.  Perhaps it
should be assigned to Amit Jain who probably has the best understanding of
all the S3DataStore changes in 1.6.

[0] - https://issues.apache.org/jira/browse/OAK-5977

-MR


On Thu, Mar 23, 2017 at 8:15 AM, Chetan Mehrotra 
wrote:

> Hi Team,
>
> As part of OAK-5976 I am trying to collect topics around various
> enhancements done in Oak 1.6 release which we should document and make
> end user aware of them and take benefit of.
>
> For now I have covered various topics in Indexing, Document NodeStore
> new features, Observation etc.
>
> Kindly create subtask under this for any new feature/enhancement which
> you can remember.
>
> Once this is done I would like to link to those new changes from the
> main site page!
>
> Chetan Mehrotra
>

Re: Documenting enhancements done in Oak 1.6

[Angela Schreiber]

hi chetan

wouldn't it make more sense to generated list directly from JIRA? after
all that's exactly i would do to make sure i have a comprehensive list of
improvements and new features i was working on between oak 1.4 and 1.6.

kind regards
angela


On 23/03/17 15:15, "Chetan Mehrotra"  wrote:

>Hi Team,
>
>As part of OAK-5976 I am trying to collect topics around various
>enhancements done in Oak 1.6 release which we should document and make
>end user aware of them and take benefit of.
>
>For now I have covered various topics in Indexing, Document NodeStore
>new features, Observation etc.
>
>Kindly create subtask under this for any new feature/enhancement which
>you can remember.
>
>Once this is done I would like to link to those new changes from the
>main site page!
>
>Chetan Mehrotra

problem on oak jcr sql2 query

[Ancona Francesco]

Hi all,
we use SolrSrerver for fulltext searches; both on metadata both on content 
binary.
In general i have to find all nodes nt:file that contain the word "company" or 
all nodes that have childs nt:resource that contain the same word.

Unfortunately if upload e file (so a node that is a nt:resource) and i use this 
query
SELECT p.* FROM [nt:file] as p where contains(p.*,''company ')

Solr find result  but the RowIterator doesn't return anything.

Instead the above query works
SELECT p.* FROM [nt:resource] as p where contains(p.*,'company')
But doesn't find nt:file nodes

Can you help me ?

Thanks in advance.


[cid:image002.png@01D2A3E8.D7747740]
Francesco Ancona | Software Dev. Dept. (SP) - Software Architect
tel. +39 049 8979797 | fax +39 049 8978800 | cel. +39 3299060325
e-mail: francesco.anc...@siav.it | www.siav.it

I contenuti di questa e-mail e dei suoi allegati sono confidenziali e riservati 
esclusivamente ai destinatari.
L'utilizzo per qualunque fine del presente messaggio e degli allegati così come 
la relativa divulgazione senza l'autorizzazione del mittente sono vietati.
Se avete ricevuto questa e-mail per errore, vi preghiamo di distruggerla e di 
comunicarcelo.
I dati personali sono trattati esclusivamente per le finalità della presente 
comunicazione in conformità con la legislazione vigente (D.lgs. 196/2003 
"Codice Privacy").
Per informazioni: SIAV S.p.A. - s...@siav.it - 049 8979797

The contents of this e-mail and its attachments are confidential and reserved 
exclusively to the recipients.
The use for any purpose of this message and attachments as well as its 
disclosure without the consent of the sender is prohibited.
If you have received this email in error, please destroy it and notify us.
Personal data shall be processed solely for the purposes of this notice in 
accordance with current legislation (Legislative Decree no. 196/2003 "Code").
For more information: SIAV S.p.A. - s...@siav.it - 049 8979797

Documenting enhancements done in Oak 1.6

[Chetan Mehrotra]

Hi Team,

As part of OAK-5976 I am trying to collect topics around various
enhancements done in Oak 1.6 release which we should document and make
end user aware of them and take benefit of.

For now I have covered various topics in Indexing, Document NodeStore
new features, Observation etc.

Kindly create subtask under this for any new feature/enhancement which
you can remember.

Once this is done I would like to link to those new changes from the
main site page!

Chetan Mehrotra

Re: New JIRA Components

[Chetan Mehrotra]

On Thu, Mar 23, 2017 at 7:27 PM, Davide Giannella  wrote:
> otherwise I would expect to have
> property-index, lucene-index, solr-index or whatever will come (if) in

We already have 'lucene' and 'solr' component for them. 'indexing' is
referring to logic mostly present in AsyncIndexUpdate and IndexUpdate
classes or any work to be done in that area.

Chetan Mehrotra

Re: Timeout on Oak Queries ?

[Davide Giannella]

On 23/03/2017 11:12, Ian Boston wrote:
> Hi,
> Is it possible to configure a maximum execution time for Oak queries ?
>
> Other "database" systems often monitor the time a query is taking and kill
> if if it exceeds a time limit to avoid long running queries causing outages.
>
>

I'm aware of "timeouts" on node reads but not on time. So we cancel a
query that iterated over a certain amount of nodes or as of 1.6 may hit
the traversal index https://issues.apache.org/jira/browse/OAK-4888.

Not aware on time constraints. I think though it will be a good feature
to add if not there.

Davide

Re: New JIRA Components

[Davide Giannella]

On 23/03/2017 09:11, Chetan Mehrotra wrote:
> 1. query - For any issue related to QueryEngine

+1

> 2. indexing - For any issue related to sync or async indexing
> 3. property-index - For any issue in Property index implementation

I'd say we stick only with `indexing`; otherwise I would expect to have
property-index, lucene-index, solr-index or whatever will come (if) in
the future.

Davide

Timeout on Oak Queries ?

[Ian Boston]

Hi,
Is it possible to configure a maximum execution time for Oak queries ?

Other "database" systems often monitor the time a query is taking and kill
if if it exceeds a time limit to avoid long running queries causing outages.

Best Regards
Ian

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Ian Boston]

Hi,
Based on the page fault behaviour, I think the areas mapped and reported by
pmap are being actively accessed by the JVM. The number of page faults for
Oak 1.4.11 is well over 2x the number of page faults for Oak 1.0.29 on the
same VM, with the same DB when performing an oak-run offline compaction.
This is on the same VM with the same repository in the same state. The Tar
files are not the same, but 1 copy of the tar files is 32GB in both
instances, 1.4.11 maps 64GB as mentioned before.

I dont know if its the behaviour seen in OAK-4274. I have seen similar in
the past. I was not confident that a GC cycle did unmap, but it would be
logical.
Best Regards
Ian

On 23 March 2017 at 09:07, Francesco Mari  wrote:

> You might be hitting OAK-4274, which I discovered quite some time ago.
> I'm not aware of a way to resolve this issue at the moment.
>
> 2017-03-22 16:47 GMT+01:00 Alex Parvulescu :
> > Hi,
> >
> > To give more background this came about during an investigation into a
> slow
> > offline compaction but it may affect any running FileStore as well (to be
> > verified).
> > I don't think it's related to oak-run itself, but more with the way we
> map
> > files, and so far it looks like a bug (there is no reasonable explanation
> > for mapping each tar file twice).
> >
> > Took a quick look at the TarReader but there are not many changes in this
> > area 1.0 vs. 1.4 branches.
> > If no one has better ideas, I'll create an oak issue and investigate
> this a
> > bit further.
> >
> > thanks,
> > alex
> >
> >
> > On Wed, Mar 22, 2017 at 4:28 PM, Ian Boston  wrote:
> >
> >> Hi,
> >> I am looking at Oak-run and I see 2x the mapped memory between 1.0.29
> and
> >> 1.4.10. It looks like in 1.0.29 each segment file is mapped into memory
> >> once, but in 1.4.10 its mapped into memory 2x.
> >>
> >> Is this expected ?
> >>
> >> Its not great for page faults.
> >> Best Regards
> >> Ian
> >>
>

Re: Metrics support in Oak

[Michael Dürig]

Hi,

I followed up with https://issues.apache.org/jira/browse/OAK-5973 to 
discuss the particulars.


Michael

On 23.03.17 09:36, Ian Boston wrote:

Hi,

IIRC (a) is doable and the prefered way of naming metrics. In other systems
that use Metrics they typically use the package or class name, sometimes an
API classname, in the same way that loggers do. This makes it much easier
to process and report on blocks of functionality at the reporting stage.
For instance when the metrics are ingested into InfluxDB using Grafana as a
front end they can be filtered effectively on the metrics name.

Some background (mostly for the wider community)

 Oaks MetricsRegistry is deployed as a service into Sling with a name the
name "oak". Sling has its own MetricsRegistry exposed as a service with the
name "sling". The reporting tools aggregate all the MetricsRegistries
prefixing them with their service name. Hence the Oak MetricsRegistry
metrics will all be prefixed with "oak-" when reported.

That means Oak doesn't need to differentiate itself from other metrics, but
(a) is a good idea to avoid 100s of metrics all in 1 namespace.
MetricsRegistries are designed to scale to 1000s.

Anyone using a MetricsRegistry service should bind to a the "sling"
registry service or create their own and register it with a unque name as
is done here [1]. Thats the runtime instrumentation bundle, service named
"woven".

+1 to (a)

Best Regards
Ian


1
https://github.com/ieb/slingmetrics/blob/master/src/main/java/org/apache/sling/metrics/impl/MetricsActivator.java#L79

On 21 March 2017 at 12:53, Michael Dürig  wrote:



Hi,

AFAICS Oak's Metrics support exposes all Stats in a flat namespace under
"org.apache.jackrabbit.oak". I don't think this is desirable. We should (a)
either come up with a way to expose them by grouping related ones together
or at least (b) arrive at a consensus on how we construct the names of the
individual Stats in an unambiguous and standard way. Currently we have
different approaches in the various component resulting in a confusing list
of items.

My preference would be (a), but I don't know if this is doable.


Michael

New JIRA Components

[Chetan Mehrotra]

Currently any change done in indexing, property index, query engine
area done in oak-core is logged against "query" component. Given these
are bit different I propose to split the component in following way

1. query - For any issue related to QueryEngine
2. indexing - For any issue related to sync or async indexing
3. property-index - For any issue in Property index implementation

This would enable getting better understanding of issues currently
logged against "query" component

Chetan Mehrotra

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

[Francesco Mari]

You might be hitting OAK-4274, which I discovered quite some time ago.
I'm not aware of a way to resolve this issue at the moment.

2017-03-22 16:47 GMT+01:00 Alex Parvulescu :
> Hi,
>
> To give more background this came about during an investigation into a slow
> offline compaction but it may affect any running FileStore as well (to be
> verified).
> I don't think it's related to oak-run itself, but more with the way we map
> files, and so far it looks like a bug (there is no reasonable explanation
> for mapping each tar file twice).
>
> Took a quick look at the TarReader but there are not many changes in this
> area 1.0 vs. 1.4 branches.
> If no one has better ideas, I'll create an oak issue and investigate this a
> bit further.
>
> thanks,
> alex
>
>
> On Wed, Mar 22, 2017 at 4:28 PM, Ian Boston  wrote:
>
>> Hi,
>> I am looking at Oak-run and I see 2x the mapped memory between 1.0.29 and
>> 1.4.10. It looks like in 1.0.29 each segment file is mapped into memory
>> once, but in 1.4.10 its mapped into memory 2x.
>>
>> Is this expected ?
>>
>> Its not great for page faults.
>> Best Regards
>> Ian
>>

Re: Discrepancy between addAccessControlEntry and clear on versioned node

[Angela Schreiber]

hi marco

On 23/03/17 09:08, "Marco Piovesana"  wrote:

>Hi all, I was trying to change the permissions on a *versioned* node and i
>found two things that I don't quite understand:
>1) If i try to do an AccessControlUtils.addAccessControlEntry(...) i got
>an
>error if the node in not checked-out (and this seems consistent with what
>written on JCR-1639
>pache.org%2Fjira%2Fbrowse%2FJCR-1639=02%7C01%7C%7C01fba7b52c3d4f6e5b1
>408d471c6bde3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636258545789584
>278=Q3h1IR0CUjcHWF87kf2YGCrzIHlhO7Gve0F44w6QRPg%3D=0>).

afaik this is covered by the "VersionEditor" that asserts that versionable
nodes are checked-out when changes occur.

>However I can do an AccessControlUtils.clear(...) without any error. Why?

looking at the "VersionEditor" class it seems that the check is only
performed for the following operations:
- propertyAdded(PropertyState)
- propertyChanged(PropertyState, PropertyState)
- propertyDeleted(PropertyState)

however not for
- childNodeAdded(String name, NodeState after)
- childNodeRemoved(String name, NodeState after)


since i am not the author of that code, i don't know the reason for
this... would have expected the same check to be performed there.

>Aren't they both changing the ACL?

yes... are you calling save and thus make sure you trigger the
'VersionEditor'?
if you do, my guess would be that it's may not trigger the
checkin-state-verifying methods if the whole subtree is removed... but
that's just a wild guess... i didn't verify if that was really the
case that might be a bug in the versioning code.

>
>2) When I do AccessControlUtils.addAccessControlEntry(...) the error that
>i
>receive is: *OakVersion0001: Cannot add property jcr:mixinTypes on checked
>in node*. Why a change on the ACL should change the *jcr:mixinTypes*? My
>node was already versionable.

the utility method will create a new policy node (if not yet present)
which in the default implementation includes adding a mixin type to the
access controlled node... but it's not really relevant here... if it
wasn't for the mixin type it would fail for some other property being
added. a checked-in node is immutable which includes any modifications
related to access control management.

>
>One last question: if I want to change the permissions without having to
>check-out the node what I have to do? (I can do that by setting the
>*jcr:mixinTypes* to *IGNORE* but i don't think is the right way... or
>not?)

you can't change the access control content associated with a checked-in
node. you have to check it out before making any modifications.

regarding the missing OakVersion exception wrt removal of nodes, may i
kindly ask you to verify if you actually persist the changes? if you do
and no exception is raised that might highlight an issue in the versioning.

kind regards
angela

>
>
>Marco.

Re: oak-benchmarks and oak-run

[Davide Giannella]

On 22/03/2017 15:45, Angela Schreiber wrote:
> Just had a first look: there are some scripts inside oak-run that can be
> used to run benchmarks (which I actually do regularly). those are missing
> in your fork oak-benchmarks module. Please make sure you move them as
> well... i will also add this to the issue.

Thanks Angela! That's why I asked an "earlier" review as it turned out
to be quite a big move and I could easily miss some things here and there.

Cheers
Davide

PS: yesterday I managed to remove no longer used dependencies from
oak-run and the jar moved from 54MB to 33MB.

Re: Metrics support in Oak

[Ian Boston]

Hi,

IIRC (a) is doable and the prefered way of naming metrics. In other systems
that use Metrics they typically use the package or class name, sometimes an
API classname, in the same way that loggers do. This makes it much easier
to process and report on blocks of functionality at the reporting stage.
For instance when the metrics are ingested into InfluxDB using Grafana as a
front end they can be filtered effectively on the metrics name.

Some background (mostly for the wider community)

 Oaks MetricsRegistry is deployed as a service into Sling with a name the
name "oak". Sling has its own MetricsRegistry exposed as a service with the
name "sling". The reporting tools aggregate all the MetricsRegistries
prefixing them with their service name. Hence the Oak MetricsRegistry
metrics will all be prefixed with "oak-" when reported.

That means Oak doesn't need to differentiate itself from other metrics, but
(a) is a good idea to avoid 100s of metrics all in 1 namespace.
MetricsRegistries are designed to scale to 1000s.

Anyone using a MetricsRegistry service should bind to a the "sling"
registry service or create their own and register it with a unque name as
is done here [1]. Thats the runtime instrumentation bundle, service named
"woven".

+1 to (a)

Best Regards
Ian


1
https://github.com/ieb/slingmetrics/blob/master/src/main/java/org/apache/sling/metrics/impl/MetricsActivator.java#L79

On 21 March 2017 at 12:53, Michael Dürig  wrote:

>
> Hi,
>
> AFAICS Oak's Metrics support exposes all Stats in a flat namespace under
> "org.apache.jackrabbit.oak". I don't think this is desirable. We should (a)
> either come up with a way to expose them by grouping related ones together
> or at least (b) arrive at a consensus on how we construct the names of the
> individual Stats in an unambiguous and standard way. Currently we have
> different approaches in the various component resulting in a confusing list
> of items.
>
> My preference would be (a), but I don't know if this is doable.
>
>
> Michael
>

Discrepancy between addAccessControlEntry and clear on versioned node

[Marco Piovesana]

Hi all, I was trying to change the permissions on a *versioned* node and i
found two things that I don't quite understand:
1) If i try to do an AccessControlUtils.addAccessControlEntry(...) i got an
error if the node in not checked-out (and this seems consistent with what
written on JCR-1639 ).
However I can do an AccessControlUtils.clear(...) without any error. Why?
Aren't they both changing the ACL?

2) When I do AccessControlUtils.addAccessControlEntry(...) the error that i
receive is: *OakVersion0001: Cannot add property jcr:mixinTypes on checked
in node*. Why a change on the ACL should change the *jcr:mixinTypes*? My
node was already versionable.

One last question: if I want to change the permissions without having to
check-out the node what I have to do? (I can do that by setting the
*jcr:mixinTypes* to *IGNORE* but i don't think is the right way... or not?)


Marco.