Hello Damien,

On 05 Mar 2014, at 12:20 pm, Damien Martin-Guillerez 
<[email protected]> wrote:

> After a disk quota excess, our ACE server started to behave weird: when a new 
> target arrives with only one bundle in the deployment list, the deployment 
> fails with "[ERROR] 11:35:02 (deployment) Stream does not contain a valid Jar 
> / java.io.IOException: Unknown/unexpected status code: 500”. When looking at 
> the server log, I get :
> 2014.03.05 12:14:03 WARNING - Bundle: org.apache.ace.deployment.servlet - 
> 500:Could not deliver package - org.apache.felix.log.LogException: 
> org.apache.ace.deployment.servlet.AceRestException: 500:Could not deliver 
> package
> …
> caused by a connection refused.

If at some point the server could no longer write to disk because of those 
quota, and you're getting error messages when a target tries to deploy an 
update, a few things could be wrong.

When a target polls, the server first fetches the deployment repository, looks 
up the version (or versions) and calculates the (delta of) bundles that need to 
be sent. It could be that this deployment repository is corrupt. On disk it is 
stored as a gzip'd XML file in the bundle cache of the repository bundle. So 
that's one place to look. Another possibility is that one of the artifacts or 
the index in the OBR is corrupt. The index (repository.xml in the store folder) 
you can always delete and ACE will recreate it. If any of the artifacts is 
corrupt, try deleting it via ACE and then upload it again.

> Before filing any bug reports, I’d like to do two things:
>       1. try updating the ACE server to latest trunk version (I’m running 
> trunk revision 1555357). Anyway, the latest jenkins build is failed (#213 
> https://builds.apache.org/job/ACE-trunk/) and I can’t figure out a way to 
> simply update the server without crushing the bundle cache of the server. Is 
> latest trunk version safe to use? Is there’s a way to update without losing 
> the data?

In theory it's a matter of "updating" the bundles. Right now we don't have a 
standard way to do that. We are shipping releases based on a bnd feature that 
creates an executable jar, and the current release of bnd has an issue that 
prevents bundles from being updated (if you just replace the old jar with the 
new one and launch again). This has been fixed and will be part of the next 
bnd, so once that is released, we will start using that. See: 
https://github.com/bndtools/bnd/issues/424

>       2. Try to refresh / reload data from the OBR. Is that possible? Or 
> should the data always be fresh? Or maybe there’s some file that might be 
> broken but I cannot find it (the single deployed bundle on the repository is 
> correct).

See above, if the bundle is okay, it could still be the "repository.xml" file 
that is broken.

Greetings, Marcel

Reply via email to