[
https://issues.apache.org/jira/browse/SLING-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123064#comment-15123064
]
Carsten Ziegeler commented on SLING-5457:
-----------------------------------------
I'm not sure if we really should handle the case if there is more than one tool
doing similar stuff at the same time. There is no way that the OSGi installer
can detect that someone else is doing bundle actions as well.
There is no way to enforce a locking to have an atomic stop/update operation.
We could maybe catch the exception and retry the operation. However I don't
think that is really going to work in all cases as your other thread might
simply start the bundle again.
> 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
>
> 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.4#6332)
