bdelacretaz commented on a change in pull request #18:
URL:
https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/18#discussion_r648086729
##########
File path:
src/main/java/org/apache/sling/jcr/repoinit/impl/RepositoryInitializerFactory.java
##########
@@ -122,14 +124,58 @@ public void processRepository(final SlingRepository repo)
throws Exception {
continue;
}
final List<Operation> ops = parser.parse(new
StringReader(script));
- log.info("Executing {} repoinit operations",
ops.size());
- processor.apply(s, ops);
- s.save();
+ String msg = String.format("Executing %s repoinit
operations", ops.size());
+ log.info(msg);
+ applyOperations(s,ops,msg);
}
}
} finally {
s.logout();
}
}
}
+
+
+ /**
+ * Apply the operations within a session, support retries
+ * @param session the JCR session to use
+ * @param ops the list of operations
+ * @param logMessage the messages to print when retry
+ * @throws Exception if the application fails despite the retry
+ */
+ private void applyOperations(Session session, List<Operation> ops, String
logMessage) throws RepositoryException {
+
+ RetryableOperation retry = new
RetryableOperation.Builder().withBackoffBaseMsec(1000).withMaxRetries(3).build();
Review comment:
A hardcoded setting for the number of retries is what I'd like to avoid.
What if someone thinks their operation is still failing with 3 retries but
would work with 4 retries? Having the backoff duration hardcoded is probably
ok, but I don't see a good reason for hardcoding the max retry count.
Defaulting to 3 is certainly good.
--
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]
