You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2012/06/27 09:03:42 UTC
[jira] [Created] (SLING-2523) Improve the JCR Installer
Carsten Ziegeler created SLING-2523:
---------------------------------------
Summary: 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
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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455742#comment-13455742 ]
Carsten Ziegeler commented on SLING-2523:
-----------------------------------------
The installer itself uses already kind of a queue - it's differently implemented though. All the other problems you're referring to have been fixed in the meantime.
> 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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Tommaso Teofili (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455703#comment-13455703 ]
Tommaso Teofili commented on SLING-2523:
----------------------------------------
Hi Carsten,
thanks for your comments!
I think the queue idea is nice and I agree syncing should be improved therefore I'll rework the patch accordingly.
I'll post a new patch as soon as I've the new impl in place.
Thanks :-)
> 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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402247#comment-13402247 ]
Carsten Ziegeler commented on SLING-2523:
-----------------------------------------
Currently it doesn't work in the desired way, in some cases you even end up with two (or more) calls to the OSGi installer even if there is a single jcr observation event.
> 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
>
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2523) Improve the JCR Installer
Posted by "Tommaso Teofili (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tommaso Teofili updated SLING-2523:
-----------------------------------
Attachment: SLING-2523_1.patch
first version of a patch using a single observation listener.
Also the UpdateHandler has been refactored out to a delegated class and some of the previously used classes which are not used anymore (i.e. WatchedFolder) have been removed.
Still to be done: collecting possibly related changes in one single change to avoid installing the same resource multiple times (e.g. an OsgiConfig which many properties changing at the same time).
> 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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455710#comment-13455710 ]
Bertrand Delacretaz commented on SLING-2523:
--------------------------------------------
Dunno how far you're going with the queue idea (haven't looked at your patch so far) but it might be interesting to use a (priority?) queue for *all* installer operations.
Problems that we've seen in complex upgrade scenarios (replace 150 bundles with 160 new ones at startup) include the installer getting confused as its core bundle was restarted, the installer/listener combo getting confused with the run levels control due to similar things happening.
Using a persistent queue with simple testable logic to aggregate and prioritize operations might help.
> 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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "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
[jira] [Updated] (SLING-2523) Improve the JCR Installer
Posted by "Tommaso Teofili (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tommaso Teofili updated SLING-2523:
-----------------------------------
Attachment: SLING-2523_2.patch
new version of the patch which avoids sync issues if any observation event reach the installer before the rendezVous phase ends.
Still need some time for making the other changes.
> 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, SLING-2523_2.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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506523#comment-13506523 ]
Carsten Ziegeler commented on SLING-2523:
-----------------------------------------
New patch looks good to me, it fixes the sync problem. I guess using a queue makes the code simpler - just a suggestion :)
> 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, SLING-2523_2.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
[jira] [Commented] (SLING-2523) Improve the JCR Installer
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402070#comment-13402070 ]
Bertrand Delacretaz commented on SLING-2523:
--------------------------------------------
> ...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"...
IIRC this is exactly the reason for the current design where an observation event just sets a flag or timer, and a separate thread acts on it only if no events have been received in a given amount of time.
(I'm not saying the current design needs to stay as is, but there might be some good things in it ;-)
> 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
>
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira