ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Pouwelse <>
Subject Re: How to keep ace performance consistent
Date Fri, 10 Jan 2014 15:07:53 GMT
Hi Marcel,

2014/1/10 Marcel Offermans <>

> Hello Bram,
> On 09 Jan 2014, at 11:55 am, Bram Pouwelse <> wrote:
> > The issue with the deploymentversionlimit is when I re-configure the
> > deployment version limit after using Ace for a while.
> From re-reviewing the code I still do not see a problem, even when
> reconfiguring the limit, it should be applied every time a new version gets
> added to that repository. Can you describe the steps to reproduce this
> issue?
I'll try to reproduce the issue on a fresh instance and provide you with
the steps to reproduce

> > I noticed that the
> > repository file was growing over time [1] and wanted to know if that was
> > causing the performance degradation and if there is a way to keep it from
> > growing that fast ;).
> You can. This 'deploymentversionlimit' is one. Roughly, the deployment
> repository keeps track of all versions of deployments for each target,
> where a deployment lists all artifacts. So its size is rougly: targets *
> versions * artifacts. That is also why it can grow quite quickly. From this
> formula it's easy to see how to limit its growth. Having less targets or
> artifacts makes little sense, those are givens, but having less versions
> does make some sense, which is why we introduced that limit.
> Another parameter to tweak is (and now I risk confusing you) to limit the
> number of old versions of the deployment repository to keep around. As you
> might have seen, every time you make a change, a new version of the
> deployment repository is calculated and saved on disk. All old versions
> remain on disk as well. There is a configuration option that you can set
> for each repository, in the org.apache.ace.server.repository.factory
> configurations called "limit" which allows you to set the number of old
> versions of the file it should keep for that repository. Now this only
> saves you disk space, since ACE does not do anything with these old
> versions anyway, except keep them around as a record of what has changed
> over time. You don't always need that record, which is why we introduced
> this option.
I've seen that and already limited the amount of copies.

> > If it's (currently) not possible to configure the deploymentversionlimit
> > after you start using Ace I'll start over with a clean server and see how
> > that works out.
> It should work. Let's work together to find and fix the issue.

Ok :)

> > I've watched the presentation Jago and jou did after you mentioned it in
> an
> > earlier thread on this list and I'm already experimenting with it to see
> > how this works out for us.
> Let me know if we can help. The gogo shell is not always the easiest to
> understand. I would be happy to share what we have if that helps you.
I've found some gogo shell sample code in an earlier thread which helped me
a lot already. My current deployment implementation uses a bndrun as input
and creates features and distributions based on the name of the bndrun file
and project (deploying test.bndrun from project-x makes sure all bundles
listed in the bndrun are copied to Ace, creates a feature "project-x-test"
and a distribution test). This is in Java and using the rest API.

Now I'm trying out the ContinuousDeployer that is "shipped" with Ace but
still have to work on creating features based on the bndrun files. If you
have anything that you can share that would help me with this that would be

During the deployment using ContinuousDeployer I somtimes get an error
Uploading released resource:
 org.amdatu.web.resourcehandler/1.0.3/osgi.bundle -
java.lang.IllegalStateException: Exepected 1 result ofter copy

I've exported all bundles from my project and listed my project release
repository and the amdatu repo's as release repository locations, running
the deployment again  "solves" the issue for now.

> Greetiings, Marcel

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