Earlier today, Apache ACE version 2.0.1 was released and can be downloaded from a nearby mirror. This is the second top-level release we made, and it contains many new features and improvements. The most important and interesting ones are presented in this article. A more detailed list of all the issues that were resolved can be found in the Release Notes.
The management agent
One of the biggest changes we did was to re-build the management agent from scratch. This was done for several reasons. For one, we wanted to make the agent self-contained, requiring nothing more than the APIs that the framework already provides and sharing just the bare minimum for resource processors to work. This means that there is now very good isolation between the agent and any application that gets installed. Another thing we wanted to address is to make the agent more flexible. We’ve introduced an API that can be used to implement custom control strategies, and the “default controller” that we ship is a lot more powerful and intelligent than before. For one it has capabilities to resume downloads, a great plus for environments where downloads are slow and flakey (think GPRS and 3G connections). It can also first download and then install, or, like before, do a streaming install. Versions that are known not to work won’t be re-installed time after time, but the agent will instead wait for a newer version to become available. Logging has been improved, and we’ve leveraged quite a few bugfixes in the Apache Felix Deployment Admin implementation. Finally, the agent can now also update both resource processors and itself, so really all aspects of the installation can be kept up to date. Apache ACE supports multiple different agents, so you can optimize the agent for different types of targets.
The server has mainly seen optimizations to its codebase that are important when running in production. For one, the audit logs it keeps can be limited in size, allowing you to limit the total amount of disk space that is used more effectively. Another thing we did was to allow you to specify how many old versions of repositories you want to keep. We’ve also added a “relay server” configuration that can be used as a kind of “proxy” that synchronizes with the master server and can be used to distribute the load of many targets polling for data. Technically, this was not something new, but we now exposed it explicitly to make it easier for people to setup. Internally we upgraded to a newer version of Apache Felix HTTP Jetty, which brings speed improvements and some much needed bugfixes.
Like the server, the client has seen a lot of optimizations: XML data is sent over the network and stored on disk in a compressed format (often saving over 90% of disk space over the uncompressed files). Furthermore, the deployment repository can be optimized to keep a limited number of old versions per target. This again saves a lot of disk space and when targets poll for updates regularly, has no downsides. The client itself has undergone considerable profiling, resulting in a much improved performance when dealing with lots of targets that used lots of configuration templates. This included much optimized filter handling used in all associations. All in all, this has resulted in a speedup of more than an order in magnitude, and we have a few extra improvements still scheduled for future releases.
Another thing we improved are the REST and GoGo Shell interfaces, and to a lesser extent the Vaadin based WebUI. The REST endpoint was refactored a bit internally, and a timeout was added to its sessions. The GoGo Shell interface was extended with many new commands and is now ideally suited for automated deployment, for example from a Continuous Deployment server such as Jenkins or Bamboo. For those of you present last year at EclipseCon Europe, or earlier this month at ApacheCon NA in Denver, we already previewed this functionality there. The shell can now also be scripted in many different ways, and we’ve already leveraged that when doing the extensive profiling. One thing we should probably do is write a book on the GoGo Shell, as it is extremely powerful but poorly documented.
The biggest improvement in our build process is that we now fully leverage semantic versioning based on Bndtools. We’ve integrated this in both our off-line build and the automatic compilation inside of Eclipse, so any semantic versioning violations are immediately visible. As far as I know we are one of the first large projects doing this. We had to make sure we use the same compiler both in Eclipse and in the off-line build (which means using ECJ) and use the same settings, but after doing that it works like a charm and really helps us versioning things correctly. We also chose to semantically version our releases as a whole, always making sure the version bump of the release is equal to the largest change within the project as a whole. We had already streamlined our release process when we did the 1.0.o build and are now in a position where we can quickly (within 15 minutes) prepare a whole release.
If there is one area that still needs some work (and love) it’s the Apache ACE website. It has been improved since our previous release, with many new pages of information, but since you can never have enough documentation and some things really need to be explained better I think more work is in order here. Still, people will probably appreciate sections on the new agent, the shell scripting and a page on how to write your own resource processor and accompanying helpers.
All in all, in less than a year after our first release, as a team we can be very proud of what we did. The 2.0.1 release is a big step in the right direction in many areas and we’ve definitely fixed a lot more issues than were raised. That does not mean we’re almost done though, as we still have plans to update our internal “multi-tenancy” model so we can easily support bigger topologies, and provide more speed improvements. Also expect some work on an “easier to use” way of providing configuration data and templates, as the official specification for Auto Configuration and its XML files are not the most user friendly beasts on the planet. Furthermore, as we get more feedback from the community, we would also love to grow our team of committers, and get some fresh blood involved! And we promise to start releasing more often! 🙂