ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-168) Check version validity before publishing to targets
Date Wed, 24 Aug 2011 15:08:29 GMT

    [ 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

        

Mime
View raw message