BlackBadger (the distributed ANT runtime) Introduction

Next week we launch the BlackBadger project and I will be talking about it first at EuroOSCON and then the following month at the Netherlands Java User Group .  BlackBadger is an open source project from SpikeSource that forms a platform for running and scheduling tests across a wide range of hardware.

Okay so that all sounds rather dull and not very exciting, so let me try that again.  Blackbadger implements a wide area state-machine across multiple machines using the Apache Ant utility as its deployment language.

Let us take a typical production example. You have your web server, database server and application server.  In some environments these may be all on the same machine or split across multiple machines.  But how could you test these different setups in such a way that you could measure their differences and evaluate the performance of each setup under different loads?  Sort of questions we want to answer without creating too much administration overhead include:

  • Is having a database server on its own server giving me any greater throughput?
  • At what point should I provision a separate machine for the application server?
  • How do I do this without having to do a lot of configuration rewritting?

This is the sort of problem Blackbadger was designed to solve.  You describe your system as a whole in a very easy to use XML file.  You would have a descriptor block for say the database, one for the web server and one for the application server.  You can then drag these blocks onto different machines and BlackBadger will automatically replumb all the configuration parameters so the application server can still talk to the database server etc.

Changing the production environment around is a very quick and easy operation, without having to wade through configuration files when something changes.

BlackBadger consists of a master and slaves (or WeeBadgers).  A WeeBadger is a small Java application that runs on each machine in the farm and is used to communicate with the MasterBadger and manage the execution of the state machine.  The state-machine consists of as many states as the test file wishes, and should any state fail for whatever reason, then all execution is halted and moved to the final state.  The MasterBadger ensures that each slave machine executes in the same state and doesn't get ahead of itself. 

Let us look at a quick high-level example assuming we have INIT, DEPLOY, RUN, TERMINATE states.  The INIT state would run on each machine and this could involve some ant code that would make sure the environment was setup, for example, deleting any old directories or log files.  The DEPLOY state could then install the software that is required to be run, and then start the execution of base servers.  The RUN state could then run the test software, such as Apache JMeter, and once it was finished, all the machines would move to the TERMINATE state, shutting down servers where necessary.

Each state is a piece of Ant script that is executed and monitored and a state is deemed to have failed, if the ant code throws an error or doesn't complete in a specific time period.

Later this week, I will discuss how the XML file used to describe this production system and how through a very clever variable system, you don't have to mess around with configuration files when you move things around.  I will also look at each component and how we execute the system, including a few screenshots of the SWT MasterBadger application used to manage the tests.


Recent Cloud posts

Recent JAVA posts

Latest CFML posts

Site Links