[
https://issues.apache.org/jira/browse/SLING-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved SLING-5457.
-------------------------------
Resolution: Fixed
Assignee: Karl Pauls
Ok, I got it working after all.
It turned out that the test didn't really test what it was supposed to be
testing (it ended-up working because it was counting events generated by the
restart bundle task). I don't even think it triggered the retry for the update
task at all.
Now with a test that actually does trigger the update retry and checks the
amount of retries it is clear that the retries do happen directly. However, it
turns out this is not because of the compact or the CYCLE (as suspected by
[~dsuess] and I, respectively) but due to the BundleTaskCreator listening to
bundle state changes and triggering retries to be sure.
That certainly does seem like a somewhat round-about way of doing it so I think
it is a good idea to lock some more into all of this as part of SLING-6522.
For now, I committed a reworked solution (it's a good thing we looked at the
test again because now that I have a working version it turned out there where
some bugs in the patch) together with the test in r1783162.
With that, I'll resolve this issue and assume we are going to work on
improvements under SLING-6522 (please reopen this issue if r1783162 doesn't
work for you).
> OsgiInstaller should retry to start bundles on failures
> -------------------------------------------------------
>
> Key: SLING-5457
> URL: https://issues.apache.org/jira/browse/SLING-5457
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: Installer Core 3.6.4
> Reporter: Jörg Hoh
> Assignee: Karl Pauls
>
> The OsgiInstaller doesn't update a bundle properly, if there's an exception
> from the framework.
> I have this exception:
> {code}
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent
> RESOLVED
> 11.12.2015 14:09:36.753 *INFO* [FelixStartLevel] my.custom.bundle BundleEvent
> STARTING
> 11.12.2015 14:09:36.754 INFO [OsgiInstallerImpl]
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask Removing failing
> update task - unable to retry: BundleUpdateTask:
> TaskResource(url=jcrinstall:/apps/myapp/install/my.custom.bundle-1.5.6-SNAPSHOT.jar,
> entity=bundle:my.custom.bundle, state=INSTALL,
> attributes=[org.apache.sling.installer.api.tasks.ResourceTransformer=:28:84:15:,
> Bundle-SymbolicName=my.custom.bundle, Bundle-Version=1.5.6-SNAPSHOT],
> digest=1449838063263)
> org.osgi.framework.BundleException: Bundle my.custom.bundle [252] cannot be
> update, since it is either starting or stopping.
> at org.apache.felix.framework.Felix.updateBundle(Felix.java:2311)
> at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:995)
> at
> org.apache.sling.installer.core.impl.tasks.BundleUpdateTask.execute(BundleUpdateTask.java:92)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:847)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:689)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:265)
> at java.lang.Thread.run(Thread.java:767)
> {code}
> I don't know for what reason the Felix.updateBundle() failed (see also
> FELIX-5138 to get some more information in this case), but from my point of
> view there should be a dedicated error handling just for the
> {code}BundleImpl.update{code} call. Does it make sense to retry the
> installation at a later point in time (maybe 3 times at max)?
> (I got this exception when I deployed a large number of bundles through the
> JCR installer. It happens only once in a while, but it's an annoying task to
> fix it manually.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
