[MAGNOLIA-5385] Make Autogeneration thread/clustering safe Created: 14/Oct/13  Updated: 24/Aug/21  Resolved: 14/Oct/13

Status: Closed
Project: Magnolia
Component/s: templating
Affects Version/s: 4.5
Fix Version/s: 5.1.1

Type: Bug Priority: Neutral
Reporter: Jan Haderka Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-5362 Introduce mechanism for performing wr... Closed
is depended upon by MAGNOLIA-5351 Moved or deleted items (pages, compon... Closed
relation
is related to MAGNOLIA-5191 Occasional ItemNotFoundException when... Closed
is related to MAGNOLIA-5387 Updating last access date is not clus... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Sprint: 5.1.1

 Description   

When opening page w/ autogenerated component for the first time, template renderer will trigger autogeneration. If there are multiple requests for display of the same page, one will fail with InvalidItemStateException or with ItemNotFoundException depending in which phase of autogeneration error occurs.
Existing code attempts to work around the issue by hiding the exception and waiting for up to half second for autogenerated node to become visible. While this diminishes possibility of reaching race condition, it still exists and should be avoided.

Solution used here should outline the way for general mechanism to handle concurrent editing once full author clustering is supported.


Generated at Mon Feb 12 04:04:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.