[jira] [Updated] (SLING-10884) i18n ResourceBundleProvider is called for every change in the repo

["Joerg Hoh (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-10884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joerg Hoh updated SLING-10884:
------------------------------
    Description: 
The i18n ResourceBundleProvider is registered as ResourceChangeListener and configured to listen to all changes within the repository.
And if the change does not affect a languageRoot (that's probably the vast majority of changes), it will always open (and close) a ResourceResolver. This comes with some overhead (500-1000 µs, depending on setup).

It should be possible to exclude some paths from being considered at all by configuration (maybe already at the level of the registration of the properties of the ResourceChangeListener, otherwise as part of the {{onChange}} method), so that the creation of this ResourceResolver can be avoided. In this case no ResourceBundles will be detected below these configured paths.

By default /var/eventing should be excluded, so that the Sling eventing operations do not trigger this ResourceChangeListener.



[1] https://github.com/apache/sling-org-apache-sling-i18n/blob/ca5472b409c2b0485af6f8a97db521ad6694e927/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L265

  was:
The i18n ResourceBundleProvider is registered as ResourceChangeListener and configured to listen to all changes within the repository.
And if the change does not affect a languageRoot (that's probably the vast majority of changes), it will always open (and close) a ResourceResolver. This comes with some overhead (500-1000 µs, depending on setup).

It should be possible to exclude some paths from being considered at all by configuration (maybe already at the level of the registration of the properties of the ResourceChangeListener, otherwise as part of the {{onChange}} method), so that the creation of this ResourceResolver can be avoided. In this case no ResourceBundles will be detected below these configured paths.
The default should remain as is.

(Although I think it could be beneficial to add /var/eventing and /var/jobs by default to these paths, as there shouldn't be ResourceBundles there, and also in these paths there are a lot of changes if Sling Jobs are used.)


[1] https://github.com/apache/sling-org-apache-sling-i18n/blob/ca5472b409c2b0485af6f8a97db521ad6694e927/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L265


> i18n ResourceBundleProvider is called for every change in the repo
> ------------------------------------------------------------------
>
>                 Key: SLING-10884
>                 URL: https://issues.apache.org/jira/browse/SLING-10884
>             Project: Sling
>          Issue Type: Improvement
>          Components: i18n
>    Affects Versions: i18n 2.5.16
>            Reporter: Joerg Hoh
>            Priority: Major
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> The i18n ResourceBundleProvider is registered as ResourceChangeListener and configured to listen to all changes within the repository.
> And if the change does not affect a languageRoot (that's probably the vast majority of changes), it will always open (and close) a ResourceResolver. This comes with some overhead (500-1000 µs, depending on setup).
> It should be possible to exclude some paths from being considered at all by configuration (maybe already at the level of the registration of the properties of the ResourceChangeListener, otherwise as part of the {{onChange}} method), so that the creation of this ResourceResolver can be avoided. In this case no ResourceBundles will be detected below these configured paths.
> By default /var/eventing should be excluded, so that the Sling eventing operations do not trigger this ResourceChangeListener.
> [1] https://github.com/apache/sling-org-apache-sling-i18n/blob/ca5472b409c2b0485af6f8a97db521ad6694e927/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L265



--
This message was sent by Atlassian Jira
(v8.3.4#803005)