[
https://issues.apache.org/jira/browse/ACE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090278#comment-13090278
]
Marcel Offermans commented on ACE-168:
--------------------------------------
It's hard to do sanity checks on URLs since there are very few assumptions you
can make about them. The provisioning server will fetch them when needed to
include them in a deployment package. That might fail for a lot of different
reasons at that moment in time. Checking if the URL happens to be accessible at
the moment you define it will catch typos, but maybe you defined an artifact
that is not available yet on purpose. Also, you'd have to perform the check on
a server and even that won't always make sense, since you can also define a
relay server that synchronizes with your server and have targets poll that
relay. In such cases the server might not need to access the URL since no
target polls it (they all talk to the relay servers). So at best we could try
to access the URL and warn the user when it fails.
Regarding the management agent trying over and over again, that's because it's
now scheduled to poll for changes and apply them every N seconds. You can
replace the scheduler with something that is a bit smarter. Again, it is kind
of hard to be smarter here, because in this example, the installation might
fail because one of the upstream OBRs is unreachable, which might be different
a couple of seconds later. So it would be too easy (and wrong) to poll and on
failure conclude that you don't ever need to try to update to this specific
version again since it could never work.
The management agent could be made a bit smarter if we would first download the
whole deployment package. That means we could also implement a resume feature
when we get download failures, and as soon as we know for sure the whole
package is downloaded, we can try installing it once. If that fails, we at
least know it's not because of the package itself. It might still be because of
any of the resource processors or because of other things installed in the
framework. Again, we can't make many assumptions here, because someone could
just install a bundle that suddenly makes the deployment package resolve when
previously it did not.
In other words, I don't think that the strategy to just keep trying is that
bad. Caching the downloaded version does help with network traffic, but at the
expense of using more disk space on the target, which is why we don't do it by
default: deployment packages are designed so they can be installed as a stream.
> Check version validity before publishing to targets
> ---------------------------------------------------
>
> Key: ACE-168
> URL: https://issues.apache.org/jira/browse/ACE-168
> Project: Ace
> Issue Type: Improvement
> Affects Versions: 1.0.0
> Reporter: Bram de Kruijff
>
> There is no sanity checking on artifacts (at least url) before publishing
> versions to targets. Simple case is an artifact with an url that is not
> accessible. This will result in any target it is associated to recieving a
> new version, polling for the deploymentpackage and getting an error
> (DeploymentServlet catches the IOException) for ever and ever and ever.
> I think URL attributes should at least be validated at creation and some way
> to prevent this endless fail cycle on every thread that handles deployment
> package requests affecting all targets would be nice.
> typical auditlog sample:
> ama-1,1314117989738,421,1314119324121,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> ama-1,1314117989738,422,1314119326080,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> ama-1,1314117989738,423,1314119328103,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> typical client log sample:
> [2011-08-23 19:16:20] ERROR: Error installing update
> [org.apache.felix.framework]
> org.osgi.service.deploymentadmin.DeploymentException: null
> org.apache.felix.log.LogException:
> org.osgi.service.deploymentadmin.DeploymentException: null
> at
> org.apache.felix.deploymentadmin.DeploymentPackageManifest.<init>(DeploymentPackageManifest.java:53)
> at
> org.apache.felix.deploymentadmin.AbstractDeploymentPackage.<init>(AbstractDeploymentPackage.java:96)
> at
> org.apache.felix.deploymentadmin.StreamDeploymentPackage.<init>(StreamDeploymentPackage.java:48)
> at
> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:194)
> at
> org.apache.ace.deployment.deploymentadmin.DeploymentAdminDeployer.install(DeploymentAdminDeployer.java:51)
> at
> org.apache.ace.deployment.task.DeploymentTaskBase.installVersion(DeploymentTaskBase.java:75)
> at
> org.apache.ace.deployment.task.DeploymentUpdateTask.run(DeploymentUpdateTask.java:57)
> at org.apache.ace.scheduler.Executer.run(Executer.java:92)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
