[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651155#comment-15651155 ] Carsten Ziegeler commented on SLING-6163: - SLING-6174 contains a patch using the new Oak functionality > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581611#comment-15581611 ] Stefan Egli commented on SLING-6163: Ok, I've created OAK-4940 to track that, let's discuss details re implementation also there. > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581577#comment-15581577 ] Chetan Mehrotra commented on SLING-6163: bq. and it only reports direct parents atm (unless we introduce it that is) May be we should as some listeners I have seen in AEM need to work with say dam:Asset but are looking for change in any of the rendition nodes under that. > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581568#comment-15581568 ] Stefan Egli commented on SLING-6163: then I doubt that OAK-4907 would help, as the nt:file is the grand-parent of these changed properties, and it only reports direct parents atm (unless we introduce it that is) > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581560#comment-15581560 ] Carsten Ziegeler commented on SLING-6163: - Correct, if a property of the jcr:content node is changed/added/removed - and only if this is a child of a nt:file node > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581543#comment-15581543 ] Stefan Egli commented on SLING-6163: At the moment this is all oak internal and hasn't been exposed yet, so we need to define this. Re the example bq. if a jcr:content node is modified IIUC you're referring to a change of a property of a jcr:content node, right? As that would not result in the nodeType of the parent of jcr:content to be reported. If properties of jcr:content are modified then only the jcr:content node is reported in OAK-4907 (name, nodeType, path of it) > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581262#comment-15581262 ] Carsten Ziegeler commented on SLING-6163: - Is that possible today - and if how? Compared to the other hints we're discussing, this is nothing we expose to the registration of ResourceChangeListeners - this is internally done by the JcrResourceListener for all RCLs > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581165#comment-15581165 ] Chetan Mehrotra commented on SLING-6163: With OAK-4907 we are collecting nodeType of ancestor nodes also which I thing should help here. So this can also be type of hint /cc [~egli] > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15580009#comment-15580009 ] Carsten Ziegeler commented on SLING-6163: - I think we have three options: - we leave it as is - For files we find a way that Oak can already send us a changed event for the parent file node of jcr:content - instead of reading, we simply always send two events: changed for the jcr:content node and for it's parent, regardless whether this is a file Maybe there are more/better options? > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway > The problem is that this read is done for every change of a jcr:content node, > regardless whether this is a file. And if several props change on such a > node, it is read over and over again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6163) Improve observation of files in JCR
[ https://issues.apache.org/jira/browse/SLING-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15580003#comment-15580003 ] Carsten Ziegeler commented on SLING-6163: - As a first improvement, we only read the parent node on change events - for node added and removed we don't need to do this, as the jcr:content node is mandatory, so if it is added the above file node is added as well, same for remove > Improve observation of files in JCR > --- > > Key: SLING-6163 > URL: https://issues.apache.org/jira/browse/SLING-6163 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Resource 2.9.0 > > > Currently, if a jcr:content node is modified, and an observation event is > sent out, the jcr listener reads the parent node to find out if this > jcr:content is a sub node of a file. If so, it reports a change on the file > node. > This is required for all listeners interested in changes in files, as they > usually listen for a file node change, but not for the sub node /jcr:content > - which doesn't exist with other resource providers anyway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
