There is of course still the case where neither InstallationContext.markForRetry() is called nor the state is modified. In that case no explicit new cycle would be triggered, but instead the task would become triggered again if e.g. a new resource comes in or something happens in the OSGi container (e.g. a new bundle was deployed). This should not count as retry and therefore the retryCount should not be modified.
I am not 100% sure this is the correct approach for https://github.com/apache/sling/blob/trunk/installer/core/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInstallTask.java#L83 <https://github.com/apache/sling/blob/trunk/installer/core/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInstallTask.java#L83> but it is for sure correct for https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L229 <https://github.com/apache/sling/blob/trunk/installer/factories/packages/src/main/java/org/apache/sling/installer/factory/packages/impl/PackageTransformer.java#L229>. > On 21 Oct 2016, at 10:55, Konrad Windszus <[email protected]> wrote: > > The already existing RetryHandler does no longer need to be called from > InstallTasks then but rather only internally in the OsgiInstallerImpl once > the flag markForRetry has been set. > >> Begin forwarded message: >> >> From: Konrad Windszus <[email protected]> >> Subject: OsgiInstaller tasks: Retry behaviour/exception handling >> Date: 21 October 2016 at 10:46:21 GMT+2 >> To: [email protected] >> Reply-To: [email protected] >> >> In the context of https://issues.apache.org/jira/browse/SLING-5457 and >> https://issues.apache.org/jira/browse/SLING-6176 I am currently >> investigating the current retry behaviour for InstallTasks. In some places >> the exception is caught and something like "Retrying later" is logged (e.g. >> in >> https://github.com/apache/sling/blob/trunk/installer/core/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInstallTask.java#L83) >> while the resource state is not modified, that leads to the same task being >> executed again with the next cycle. >> >> In other places it is just giving up (e.g. for bundle updates in >> https://github.com/apache/sling/blob/trunk/installer/core/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleUpdateTask.java#L135 >> where it just sets the resource to "ignore"), see also >> https://issues.apache.org/jira/browse/SLING-5457. >> >> Currently the number of retries is not counted, so in case of retries it is >> repeated with each cycle of the installer. >> >> I would propose the following changes here: >> 1) In case an installer task throws a (runtime) exception >> (https://github.com/apache/sling/blob/trunk/installer/core/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L860), >> there is no retry at all. We just assume that all the exceptions being >> thrown from the InstallerTask are non-recoverable. The state is always set >> to ignore and the error is persisted through the OsginstallerImpl. >> 2) In case of recoverable errors the installer task should not throw an >> exception but rather call a new method "InstallationContext.markForRetry()". >> This sets a boolean flag to true. The OSGi installer will internally count >> the number of retries and log them. Once the maximum number of retries is >> reached (configurable through OSGi property) it would behave like for 1). >> >> WDYT? >> Especially for the BundleUpdateTasks it makes sense to retry here as well >> (https://issues.apache.org/jira/browse/SLING-5457). >> >> Konrad >> >
