[
https://issues.apache.org/jira/browse/SLING-9905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513414#comment-17513414
]
Stefan Egli commented on SLING-9905:
------------------------------------
[~cziegeler], few points come to mind:
* IIUC this will only consider assigned-slingId-folders for removal that have
zero topic-subfolders. But checking on some sample existing deployment there
are cases with topic-subfolders - which then would not be cleaned up (or is
that a misconfiguration of itself)?
* rolling out such a feature on a deployment which has many
assigned-slingId-folders for deletion might cause a load spike - so I was
wondering whether we should limit the number of folders deleted per (1h)
iteration, for example limit it to 16 (that limit could be applied to the first
iteration where the list is composed)
* having some test cases might be useful (I could try to find time for that)
> Provide option to include sling instance id nodes in cleanup
> ------------------------------------------------------------
>
> Key: SLING-9905
> URL: https://issues.apache.org/jira/browse/SLING-9905
> Project: Sling
> Issue Type: Improvement
> Components: Event
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: Event 4.3.2
>
>
> Currently, empty nodes for Sling job handling are removed, up to the JCR node
> specific to a Sling instance id. That node is kept in place to avoid
> unnecessary removal and recreation.
> This assumes that the instances are stable and do not frequently change.
> However, in volatile installations where new instances are constantly created
> (and old ones stopped), this leads to a growing number of nodes for each id
> ever started.
> One way would be to provide a "idle timeout" configuration - for an instance
> id it is recorded when it was first not seen anymore and if it is not seen
> for the configured time, these nodes get removed. For example, if the timeout
> is set to one day, such nodes are removed approximately one day after the
> instance was stopped.
> There are probably other ways to fix this
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
