ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: How to keep ace performance consistent
Date Thu, 09 Jan 2014 01:18:34 GMT
Hello Bram, Paul,

What Paul said is not entirely accurate. Web sessions are being cleaned up. However, with
the REST interface, sessions do currently stay around because of ACE-442 [1]. What you can
do to make the memory grow a lot less quickly is to make sure that the workspace that you
create in the REST session is being deleted again (after you've committed it back to the server).
99% of all resources are in that workspace so deleting it will free almost all the memory.
Not a permanent solution, but the best you can do until that issue is resolved.

There are two other things you can consider to improve this situation:

1) The "client" part of ACE is the one that uses the most memory. Therefore, instead of deploying
the "all-in-one" server, you can also deploy the "server", "obr" and "client" separately.
The client is only necessary when changing something in the ACE configuration. The targets
talk to the "server" (and the "server" to the "obr" to fetch the artifacts). By deploying
them separately, you can more easily simply restart the client, or just start it "on demand"
(see 2)).

2) Instead of using the REST API, you can also use the client (run it on your CI server as
part of the build) and talk to this client using a script for the GoGo shell. This is something
we added after we did the REST API, so its fairly new, but we do already use it in our CI
scenario. If you want to learn a bit more about this approach, Jago and I did a talk on it
at EclipseCon EU last year [2].

About the deploymentversionlimit, that should have worked. You should configure it before
you start using ACE, but this sounds like a bug. Is it as easy as configuring this limit and
then you instantly get this error? If so, please file a bugreport and I'll look into it. That
limit was created to make sure the server itself and the diskspace it consumes scales linearly
with the number of targets (instead of exponentially with targets * versions as it does without
the limit) so I do advise you to keep it set. Especially if you don't have targets with "really
old versions" (which happens if targets are off-line for long periods of time) and even in
such cases, all you loose is the ability for the server to send a delta between this really
old version and the current one: instead in that case it will just send everything again.
The agent is smart enough to deal with that, you're just wasting some bandwidth, sending bundles
you probably don't need. That's the trade-off.

Hope this helps.

Greetings, Marcel


On 08 Jan 2014, at 22:19 pm, Bram Pouwelse <> wrote:

> Hi Paul,
> The deployment is automated using the rest interface. Sessions not being
> closed would be my first guess but restarting Ace would close such
> sessions? The performance is not much better after restarting the ace
> server.
> The version I'm currently using is trunk from 16-11-2013
> Bram
> 2014/1/8 Paul Bakker <>
>> Hi Bram,
>> Are you using the web user interface? The problem that you are experiencing
>> is most probably related to sessions not being cleared. We are running
>> completely without the UI (we scripted deployments) and that works without
>> any problems after many deployments.
>> Besides that, on which version of ACE are you running?
>> Cheers,
>> Paul
>> On Wed, Jan 8, 2014 at 8:37 PM, Bram Pouwelse <> wrote:
>>> Hi all,
>>> I have a question regarding performance of Ace, and most important part
>> is
>>> how to keep the performance consistent over time. Now we've automated
>>> moving artifacts to Ace and converting bndrun configurations from
>> bndtools
>>> to features and distributions Ace has made it to production at our
>> company.
>>> There is one little issue, the deployments from the Jenkins server to Ace
>>> are becoming slower when we just started deployment took seconds now it's
>>> over 10 minutes. Also ace seems to need more and more memory.
>>> I've tried to change the deploymentversionlimit
>>> in conf/org.apache.ace.client.repository.cfg to 5 instead of the default
>>> value of -1 (unlimited) but after that change I get an exception that the
>>> repository is busy [1] (even after 30 minutes of waiting).
>>> Is limiting the deployment versions the way to get the performance back
>> to
>>> the level of when we just started using ace? and if so how can I resolve
>>> the "repository is busy" problem
>>> Are there other configuration options that can improve performance?
>>> Thanks!
>>> Bram
>>> [1]
>>> g! ws = (ace:cw)
>>> $ws commit
>>> gogo: ConversionException: java.lang.IllegalStateException: The
>> repository
>>> is currently busy, so no objects can be removed.
>>> ---- Debugging information ----
>>> message             : java.lang.IllegalStateException: The repository is
>>> currently busy, so no objects can be removed.
>>> cause-exception     : java.lang.IllegalArgumentException
>>> cause-message       : java.lang.IllegalStateException: The repository is
>>> currently busy, so no objects can be removed.
>>> class               :
>>> org.apache.ace.client.repository.impl.RepositorySerializer
>>> required-type       :
>>> org.apache.ace.client.repository.impl.RepositorySerializer
>>> path                : /repository/deploymentversions/deploymentversion[8]
>>> line number         : 19543

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