Package org.exoplatform.addons.documents.cleanup.service

Class CleanupSettingService

java.lang.Object
org.exoplatform.addons.documents.cleanup.service.CleanupSettingService
@Service public class CleanupSettingService extends Object
Cleanup campaign settings: platform defaults overridable via exo.properties and persisted overrides in SettingService (GLOBAL context). A campaign snapshots the effective values at launch, so later edits never affect a running campaign.

  • Field Details

    • MIN_SCAN_THREADS

      public static final int MIN_SCAN_THREADS
      Lower bound of the dry-run scan reader-thread count: never zero reader.
      See Also:

    • MAX_SCAN_THREADS

      public static final int MAX_SCAN_THREADS
      Upper bound of the dry-run scan reader-thread count. A configured value outside [MIN_SCAN_THREADS, MAX_SCAN_THREADS] is CLAMPED, never honoured: a typo in exo.properties must not be able to fan a background simulation out over the repository.
      See Also:

    • MIN_PURGE_BATCH_SIZE

      public static final int MIN_PURGE_BATCH_SIZE
      Lower bound of the purge checkpoint batch: never a batch of zero item.
      See Also:

    • MAX_PURGE_BATCH_SIZE

      public static final int MAX_PURGE_BATCH_SIZE
      Upper bound of the purge checkpoint batch. Generous — the value only decides how much progress a JVM death loses and how coarsely the bar advances, never correctness — but bounded all the same, so a typo cannot turn the progress report off for a run measured in hours.
      See Also:

  • Constructor Details

    • CleanupSettingService

      public CleanupSettingService()

  • Method Details

    • getDefaultParams

      public CleanupParams getDefaultParams()
      Returns:
      the current platform default parameters (persisted overrides, falling back to exo.properties values)

    • getEffectiveParams

      public CleanupParams getEffectiveParams(CleanupParams overrides)
      Parameters:
      overrides - partial parameters, null fields meaning 'use default'
      Returns:
      fully populated parameters, to snapshot at campaign launch

    • updateDefaultParams

      public void updateDefaultParams(CleanupParams params)
      Persists new platform defaults (overriding exo.properties values).
      Parameters:
      params - defaults to persist, null fields left unchanged

    • getBatchSize

      public int getBatchSize()

    • getPurgeBatchSize

      public int getPurgeBatchSize()
      Returns:
      items a purge processes between two progress checkpoints, CLAMPED to [MIN_PURGE_BATCH_SIZE, MAX_PURGE_BATCH_SIZE] — both ends, and logged when corrected, like getScanThreads(). It floored only at 1 before, which left the two adjacent settings asymmetric for no reason: an oversized purge batch is harmless today (it merely coarsens checkpointing) and that is exactly the asymmetry somebody copies into a setting where it is not

    • getReportRetentionCampaigns

      public int getReportRetentionCampaigns()

    • getMaxScanThreads

      public int getMaxScanThreads()
      Upper bound a campaign may ask for, which is the platform ceiling and NOT the configured default: an administrator tuning one run may go above what exo.properties sets, and no further.

      WHY IT IS NOT DERIVED FROM THE CONNECTION POOLS, which was the first proposal: half of min(JCR pool, JPA pool) lands near 150 readers on this deployment (the exo-jcr_portal pool is provisioned at 300), an order of magnitude above what the repository survives. The binding constraint is JCR workspace-cache eviction at the million-entry cap and raw repository load, not connection exhaustion — and readers deliberately hold NO pooled connection across a walk, CleanupScanService#commitThenPost committing before every blocking post precisely so that ten readers cannot pin ten connections. A pool-derived cap would license the load it looks like it is protecting.

      Returns:
      the highest reader-thread count a campaign may request

    • getScanThreads

      public int getScanThreads()
      Returns:
      the configured dry-run scan reader-thread count, CLAMPED to [MIN_SCAN_THREADS, MAX_SCAN_THREADS] — an out-of-range value is logged and corrected, never applied