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 [1] https://issues.apache.org/jira/browse/ACE-442 [2] http://www.youtube.com/watch?v=4S_zvgG_MLw On 08 Jan 2014, at 22:19 pm, Bram Pouwelse <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 >>> >>
