joerghoh commented on pull request #18: URL: https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/18#issuecomment-857440053
It is a transient problem, because mixins are also stored as part of the repo: ``` Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /jcr:system/jcr:nodeTypes/dam:cfVariationNode ``` and can fail due to concurrency (as indicated by this OakState0001 exception). Same as path creation, user creation, ACL setup etc. Moving the retries into these specific operations doesn't make much sense to me, as it would duplicate a lot of code with no benefit. There might be root causes where retry doesn't make sense because the operation will always fail (for example setting an ACL to a non-existing path). Avoiding to retry these is work because you need to review the different types of exceptions to understand if they indicate a transient or permanent failure, and if a retry makes sense. Of course we can do that, but I consider the benefit very limited, because it would save ~6 seconds (retries after 1,2 and 3 seconds) until the repoinit operation finally fails. Also situations like this (incorrect repo init statements) should never the normal case, while concurrency issues are more likely to happen. The case mentioned above with perfectly valid rep init statements led to startup failures of a more than dozen cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
