ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Flaky deployment
Date Tue, 24 Nov 2015 14:52:35 GMT
Hello Robert,
On 24 November 2015 at 13:31:02, Robert M. Mather ( wrote:

I’ve narrowed the problem down to the Gogo script I’ve been using for 
uploading bundles to the obr and linking them to a feature. I don’t know 
what’s wrong with the script and/or that method, but when I switched back 
to doing it manually in the web UI, things started working normally again. 
I created the script starting from an example given in a presentation on 
continuous deployment ( 
Conceptually, that script creates artifacts and links them all to a feature. When manually
linking artifacts you need to make sure that you end up with only a single version of a bundle
for each target. If you have more than one version linked, that won’t deploy as the Deployment
Admin specfiication prohibits having more than one version in  a deployment package.

It’s hard for me to see if that is indeed what happens when you run your script, but it’s
something worth looking out for.

Here is the script, maybe there’s some mistake I’m missing… 


sourceIndex = (repo:index /my/local/runbundle/directory) 

sourceRepo = (repo:repo OBR $sourceIndex) 

targetRepo = (repo:repo OBR "http://ace.server.url/obr/repository.xml") 

deployed = repo:cd $sourceRepo $sourceRepo $targetRepo 

workspace = (ace:cw) 

featureName = "myFeature|$(System:currentTimeMillis)" 

$workspace cf $featureName 
Since you create a new feature every time you run the script, you might end up with the situation
described above if you link more than one feature to a target.

If you’re running this in continuous deployment, I would consider adding some code to the
script that first cleans up at least the feature and all associations (and possibly even the
artifact definitions) before creating a new one.

each $deployed { 

identity = $it getIdentity 

version = $it getVersion 

name = "$identity - $version" 

url = $it getUrl 

mimetype = $it getMimetype 

if { (coll:first ($workspace la 
"(&(Bundle-SymbolicName=$identity)(Bundle-Version=$version))")) } { 

echo "artifact $name already exists" 

} { 

$workspace ca [ 








$workspace ca2f 


$workspace commit 

exit 0 


On Sat, Nov 21, 2015 at 3:07 PM, Robert M. Mather <> wrote: 

> I'm trying to deploy a set of bundles that resolves and runs fine inside 
> bndtools, but leads to errors on the (Felix) client. So far, I've seen: 
> > 2015-11-21 11:39:50 | ERROR | ACE Agent Controller | 
> org.apache.ace.agent.1.0.1 - Could not delete temporary deployment package 
> from disk 
> > 2015-11-21 11:39:50 | ERROR | ACE Agent Controller | 
> org.apache.ace.agent.1.0.1 - Installation of deployment update failed: The 
> InputStream is not a jar! Unknown/unexpected status 
> code: 500 at 
> org.apache.ace.agent.impl.ContentRangeInputStream.getHttpContentRangeInfo( 
> ~[na:na] at 
> org.apache.ace.agent.impl.ContentRangeInputStream.getContentRangeInfo( 
> ~[na:na] at 
> org.apache.ace.agent.impl.ContentRangeInputStream.prepareNextChunk( 
> ~[na:na] at 
> ~[na:na] at 
> ~[na:na] at 
> ~[na:1.8.0_40] at 
> ~[na:1.8.0_40] at 
> ~[na:1.8.0_40] at 
> ~[na:1.8.0_40] at 
> ~[na:1.8.0_40] at 
> java.util.jar.JarInputStream.<init>( ~[na:1.8.0_40] 
> at java.util.jar.JarInputStream.<init>( 
> ~[na:1.8.0_40] at 
> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage( 
> ~[na:na] at 
> org.apache.ace.agent.impl.DeploymentHandlerImpl.install( 
> ~[na:na] at 
> org.apache.ace.agent.impl.DefaultController$StreamingUpdateInstaller.doInstallUpdate( 
> ~[na:na] at 
> org.apache.ace.agent.impl.DefaultController$UpdateInstaller.installUpdate( 
> ~[na:na] at 
> org.apache.ace.agent.impl.DefaultController.runDeploymentUpdate( 
> ~[na:na] at 
> ~[na:na] at 
> org.apache.ace.agent.impl.AgentContextImpl$ 
> ~[na:na] 
> and also 
> > 2015-11-21 11:39:50 | ERROR | ACE Agent Controller | 
> org.apache.ace.agent.1.0.1 - Stream does not contain a valid Jar 
> Unknown/unexpected status code: 500 at 
> org.apache.ace.agent.impl.ContentRangeInputStream.getHttpContentRangeInfo( 
> ~[na:na] at 
> (rest of trace same as above) 
> and 
> INFO|1428/0||15-11-21 05:22:51|[ERROR] 05:22:51 (controller) Installation 
> of deployment update failed: Expected more bundles in the stream: 
> [, 
> ring.order.inject.micros-, 
> org.apache.httpcomponents.httpcore-4.3.3.jar, 
> ring.creditCard.decrypt-, 
> log4j.over.slf4j-1.7.12.jar, 
> org.apache.servicemix.bundles.json-20140107.0.0.1.jar, 
> ch.qos.logback.core-1.1.3.jar, 
> ring.conf.micros-, 
> org.apache.httpcomponents.httpclient-4.3.6.jar, 
> osgi.cmpn-, bcprov-1.53.jar, 
> com.fasterxml.jackson.core.jackson-databind-2.5.1.jar, 
> com.fasterxml.jackson.core.jackson-core-2.5.1.jar, 
>, ch.qos.logback.classic-1.1.3.jar, 
> ring.conf.cache-, 
> patronpath.wrap.pubnub-, 
> ring.util.order-, 
> ring.log.fetch-, 
> org.slf4j.osgi-over-slf4j-1.7.12.jar, 
> ring.order.process-, 
> ring.util.json-, 
> org.functionaljava-4.3.jar, 
> com.fasterxml.jackson.core.jackson-annotations-2.5.1.jar, 
> org.apache.felix.scr-2.0.0.jar, jcl.over.slf4j-1.7.12.jar, 
> ring.conf.boot-] (463)! 
To be honest, so far I don’t see any “duplicate” bundles in this list. Then again, the
fact that some bundle in the stream appears to be “missing” does mean something is wrong.
Deployment packages get created on the fly in ACE so when something goes wrong during that
creation, that is usually only noticed when a target asks for such a deployment package.

> I can't pin down whether the cause is the bundles themselves, or something 
> in the ace server/agent. The only things that have changed recently (as far 
> as I know) are upgrading to bndtools 3.0.0 and removing a set of 
> dependencies we no longer needed in our application.
In theory you should also check to make sure if the MANIFEST.MF file is indeed the first entry
in the bundle. According to the spec, it should, and most tools do respect that, but I’ve
seen “bundles” in the past that were either hand-edited, or were processed with some more
generic jar/zip tools that did not respect that.

> Is it possible that bndtools is generating jars that are invalid based on 
> the agent's verification? Has anyone else seen errors like these? 
So far we have never seen bnd(tools) generate “invalid” bundles, but I would definitely
also check my dependencies.

Ending up with more than one version of a bundle for a target would be my next guess as explained

If neither of those are the cause, the next step is probably to somehow create a scenario
that I can reproduce, or to step through the code with a debugger to get a better feel for
what goes wrong exactly.

In any case, let us know if you need more help!

Greetings, Marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message