[
https://issues.apache.org/jira/browse/SLING-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066119#comment-14066119
]
Chetan Mehrotra commented on SLING-3747:
----------------------------------------
bq. It would be cleaner IMO to make
/system/sling/installer/jcr/pauseInstallation a node, require clients to create
child nodes with unique names like com.example.packages.someInstaller, and
pause the installer as long as at least one node exists under
/system/sling/installer/jcr/pauseInstallation
Good point. Would go for that approach
> Provide a way to signal Jcr Installer to pause and resume scanning
> ------------------------------------------------------------------
>
> Key: SLING-3747
> URL: https://issues.apache.org/jira/browse/SLING-3747
> Project: Sling
> Issue Type: New Feature
> Components: Installer
> Reporter: Chetan Mehrotra
> Fix For: JCR Installer 3.1.8
>
> Attachments: SLING-3747-1.patch, SLING-3747-2.patch, SLING-3747.patch
>
>
> Currently Sling Installer JCR Provider would listen for observation event and
> would perform a rescan every 500 msec upon receiving any observation event.
> This at times cause issue when large number of bundles get updated in
> repository say via installation of bug fixing content package. Further if
> same content package also updates the repository bundle then it causes issues
> as repository bundle might get updated midway while content package is still
> being deployed
> Based on [~fmeschbe] suggestion this can be done via introducing a signalling
> mechanism between component which installs package and JCR Installer. It
> would work something like this
> # JCR Installer would listen to changes done to property
> {{/system/sling/installer/jcr/pauseInstallation}}
> # Package installer would set the above flag to true before installing the
> package and reset it back to false post installation
> # If JCR Installer detects that flag is set to true it would not scan the
> watch folders untill it get reset back to false
> This should also address the issue in cluster deployment
--
This message was sent by Atlassian JIRA
(v6.2#6252)
