Hello Klaus, On 07 Oct 2014, at 18:18 pm, [email protected] wrote:
> I want to use ACE (version 2.0.1) for deploying POS (Point of sale) java > clients. In my scenario I have hundreds or thousands of targets > (POS-clients). I developed an API around the REST-API for creation of > distributions which point to an associated feature which contains about > 100 bundles. On the other side I have developed an API (based on the > REST-API) which creates targets and connects them to the distributions. I > found out that when I import about 1000 targets then the allinone server > becomes extremely slow, when managing each kind of data (creating and > deleting distributions, targets). Allocating a working area needs about > one minute or so. Also sometimes I get exceptions from the Felix > preference service. Do you have already experiences whith a lot of > targets, are there any issues known about performance ? Can you give me > some ideas what I can do next to solve my problem. Let me start by explaining a bit about how the ACE client code works, as that will give you more insight into this problem. ACE consists of a server, a client and an OBR repository. Each can be deployed independently, but for convenience we also have an "all-in-one" version. The client is what you need to manipulate the repository, and fundamentally the client works by "checking out" a copy of the current configuration, manipulating it locally and, when done, "committing" the new configuration back to the server. Now, the client has an OSGi API (services) you can talk to, and on top of that we built three different APIs: 1. The web UI based on Vaadin. 2. The REST API. 3. The Gogo Shell API. The first two can work "over the network" with a browser or REST client being the primary users. The last one works "on the client" and is therefore usually a lot faster. We use it for all kinds of scripted access such as in continuous integration scenarios. That being said, I have a few recommendations: First of all, if you build your own API, I would consider building it directly on top of the OSGi, service based API just like the 3 existing clients do. That will be a lot quicker than interfacing, over the network, with a remote client. Second of all, you might want to consider the Gogo Shell API to script these things. We use this in continuous integration and if it helps I can provide some examples (but I probably need to know a bit more details about the deployment process you are using). Finally, we have tested ACE with 100's to 1000's of targets. I would say that is possible. I currently would not go to 10.000's of targets, our benchmarks have shown that you are running into some limits there. However, we have options to partition the targets into smaller groups within ACE, so if necessary I can go into that a bit more and explore if that is an option that could help you. Also, one thing that slows ACE down is when you have "auto configuration" XML files which are templates that have parameters that need to be substituted for each target. We are still discussing ways to optimize that. I hope this gives you some pointers/suggestions that help. Feel free to follow up if you have more questions. Greetings, Marcel
