IBX-5502: Added additional tag cleaning to limit down number of orphaned tag en…

[mateuszbieniek]

Rebase of ezsystems/ezplatform-kernel#372

Question	Answer
JIRA issue	IBX-5502
Type	bug
Target Ibexa version	v4.6
BC breaks	no

Due to how the cache is implemented in Symfony-based projects using the Redis adapter (and probably - not only Redis), entries (Members) inside a Tag (Set) are removed only when the tag is purged. Due to that, we can encounter on multiple occasions a situation, when a Tag is purged, resulting in cache items (Keys) being purged as well, but only the Tag that triggered a purge is cleaned up. All other tags that contain entries pointing to cache items that no longer exist will remain there until the affected tag is purged - which often is "never".

This results in orphaned entries in tags (or even in whole orphaned tags) filling up the memory. Memory allocated to tags in Redis is nonevictable, therefore it is freed only when purged on purpose (maxmemory-policy setting won't affect orphaned members/sets). On very big and/or constantly changing content structures, this unevictable memory allocated to orphaned tags and entries can significantly lower the amount of memory available for standard cache items to be stored.

Additional Tag purging added in this PR reduces this effect, but - unfortunately - it is not possible to resolve it fully with current Symfony's cache adapters implementation, due to the fact that there is no available interface to remove an entry from a Tag, without purging it whole - and that would result in purging cache items that were nor related to the original action performed on content.

Additional tag purging introduced by PR:

• ContentHandler::updateContent:
  Multiple content-related entries (ibx-c-<contentId>-<versionNo>-0, ibx-c-<contentId>-<versionNo>-<languageCode>, ibx-cvi-<contentId>, ibx-cl-<contentId>-pfd are orphaned in tags: l-<locationId>, lp-<locationId>, c-<contentId>-v-<versionNo>, c-<contentId>-v-<prevVersionNo>. Added purging of those tags to avoid it.

• TrashHandler::trashSubtree:
  Multiple content-related entries are orphaned (ibx-c-<contentId>-v<versionNumber>, ibx-cl-<contentId>, ibx-cvi-<contentId>, ibx-l-<locationId>-<languageCode>, ibx-c-<contentId>-<versionNo>-0, ibx-c-<contentId>-<versionNo>-<languageCode>, ibx-cvi-<contentId> ... (many more) are orphaned in tags: l-<locationId>, c-<contentId>-v-<versionNo>.

Handling those two occurrences helps to limit greatly the number of orphaned members.

My tests show, that one of the biggest culprits here is lp-<locationIdOfParent> tag, which can have multiple orphaned entries - therefore it might be a good idea to purge it as well, to avoid blocked memory in cost of potentially small performance loss - up for discussion.

This PR won't resolve the issue fully but limits the scope of it using available tools. To resolve this fully, we will need (in my opinion):

• an interface to remove entries from sets
• a garbage collector, as entries in tags might become orphaned as well when a key is evicted by Redis when maxmemory limit is reached.
  But those two are out of this PR scope.

Checklist:

• Provided PR description.
• Tested the solution manually.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review (ping @ezsystems/engineering-team).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud