[jira] [Commented] (SLING-2523) Improve the JCR Installer

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455640#comment-13455640 ] 

Carsten Ziegeler commented on SLING-2523:
-----------------------------------------

Hi Tommaso, thanks for your patch - it looks pretty good.

I think the installer needs some more syncing: the rendezvous might take some time and at the same time observation events might already occur. 
And - as you noted - collecting possibly related changes is missing, we also have the feature wish to wait before reporting changes if another observation event is occuring "right after", so e.g. if changes to the repository are done in several save operations.
I haven't thought this completely through, but I think all of this can be fairly easy solved by using a queue, so the rendezvous code as well as the observation listener adds changes into a queue
There is background thread reading from the queue, collection and assembling the changes. Once there are changes it waits for the queue for a configured time if there are new entries in the queue, if not, the current change set is reported.
However this would still need some special handling for the rendezvous part, which could be done by putting a "rendezvous start" and "rendezvous end" entry into the queue.
That's just a rough idea :)
                
> Improve the JCR Installer
> -------------------------
>
>                 Key: SLING-2523
>                 URL: https://issues.apache.org/jira/browse/SLING-2523
>             Project: Sling
>          Issue Type: Improvement
>          Components: Installer
>    Affects Versions: JCR Installer 3.1.4
>            Reporter: Carsten Ziegeler
>         Attachments: SLING-2523_1.patch
>
>
> The current implementation has some drawbacks: 
> - it registers several observation listeners
> - to handle deletes it has to register even more listeners
> - observation events are just used as markers and there is a polling thread running continously to check for changed markers and then rescan a sub tree in the repository
> - changes are not reported to the OSGi installer in one method call
> I think we can simplify and improve the implementation by
> - just registering a single observation listener for root and then do simple path matching operations
> - use the observation events to detect what has changed
> - report the changes in a single method call
> In addition it would be nice if the jcr installer waits befire reporting changes from an observation event and looks if there is not another observation event coming in "right after". This could improve situations where changes are not done by a single save but by a serious of saves

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira