February 2, 2011

Installing Apache Active MQ on Ubuntu

After creating a Sales Demonstration system for an industry trade show using Ubuntu 10.10, I decided to create a personal development system based on one of my personal favorite free operating systems, Ubuntu. An old laptop was pressed into service as a meager server on which I could refresh my admin skills and provide a target for testing prototype concepts rambling around my brain. One of the first services this little laptop will host is Apache Active MQ 5.4.2 which was released December of 2010. (Authors Note: This article has been updated to support Ubuntu 11 and ActiveMQ 5.5)

Although Ubuntu has a large collection of software available in many repositories, there is no way, currently, to perform an apt-get for Active MQ. It has to be installed by hand. Fortunately, this is a relatively simple matter. There are a couple of stumbling blocks which prevented a smooth install for me so I thought this article might help others avoid them.

Ensure you have Java installed

I prefer to have have the sun-java6-bin and sun-java6-jre packages for this purpose. I'm currently testing the free versions which come with Ubuntu. I have a separate link which describes installing sun-java on Ubuntu. It's like 5 commands; no big deal.

Initial Install

Go to the download page for Apache Active MQ and select the latest available release tarball and extract it on your server.

tar xzf apache-activemq-5.5.0-bin.tar.gz

Move it to /opt where optional software package are intended to be placed.

sudo mv apache-activemq-5.5.0 /opt

The activemq scripts expect to find Active MQ installed in /opt/activemq. I personally do not like having a non-versioned directory like that. Moving the package to /opt/activemq as would be expected by the scripts can make it difficult months down the line to upgrade. What version is installed? Will you remember? Now, this is a personal preference, but I like to know at any time what versions of software I have installed so I generally create a sym-link so the script finds things where it expects and I can see what version is installed. It is also easier to switch versions by simply linking /opt/activemq to another directory containing a different version. If it works fine, I can delete the old version, if not, I can switch the like back all this happens without changing any of the scripts. Here is how I did it:

sudo ln -sf /opt/apache-activemq-5.5.0/ /opt/activemq

Add Non-Privileged Account

It's never a good idea to run a service as root, so it is a common practice to add a dedicated user account which doesn't have much authority and run the service as this account. This will have the added benefit of making the process easier to identify with tools such as ps and top.

sudo adduser -system activemq

Some (many?, most?) systems will give a system user a false login shell. This will keep the activemq script from running so you will have to make sure the account uses the bash shell. First, open the /etc/passwd file in your favorite editor. Don't forget to use sudo as it is a privileged file. Here is the line when using vi:

sudo vi /etc/passwd

Go to the end of the list of accounts and make sure the shell for this account looks something like the following line. Don't worry about the numbers and such, but make sure the last argument contains /bin/bash and not something like /bin/false, for example, the line should look something like the following:


Recursively change the ownership of the entire activemq directory to the activemq user you just added.

sudo chown -R activemq: /opt/apache-activemq-5.5.0/

Next, sym-link the init script provided by Active MQ to /etc/init.d/activemq:

sudo ln -sf /opt/activemq/bin/activemq /etc/init.d/

Tell Ubuntu to start Active MQ on boot:

sudo update-rc.d activemq defaults

At this point you will probably get a warning about missing LSB information. LSB information is a block of information which directs how the links are made. See http://wiki.debian.org/LSBInitScripts for more details.

Now, let's build a default configuration file:

sudo /etc/init.d/activemq setup /etc/default/activemq

Change the owner and group of the config file:

sudo chown root:nogroup /etc/default/activemq

Change the file permissions so its read-write by root only:

sudo chmod 600 /etc/default/activemq

Editing the Configuration

Unfortunately, this is where you will have to begin searching through your configuration file and make changes specific to your version of software and setup. There have been some changes between releases of Active MQ so the instructions may not match what you see in your files.

Edit the newly generated /etc/default/activemq file. I'll use vi:

sudo vi /etc/default/activemq

You're looking for ACTIVEMQ_USER="". Enter the name of your activemq user name between the quotes.

Now we will configure the Active MQ broker to listen for JMX connections. Further down the file, un-comment the JMX configuration lines:

ACTIVEMQ_SUNJMX_START="-Dcom.sun.management.jmxremote.port=11099 "
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONFIG_DIR}/jmx.password"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONFIG_DIR}/jmx.access"
ACTIVEMQ_SUNJMX_START="$ACTIVEMQ_SUNJMX_START -Dcom.sun.management.jmxremote.ssl=false"

The above configuration lines enable JMX on port 11099 and use two file to control access through JMX.

The next section will specify how the shutdown script will connect to the broker (via JMX) and log into the management console to issue the shutdown command. This line will connect to broker via port 11099 and log in as controlRole with a password of abcd1234. Keep these values (or whatever you change them to) in mind as you will need to make sure they are registered in the data/jmx.password and data/jmx.access files in the next steps.

ACTIVEMQ_SUNJMX_CONTROL="--jmxurl service:jmx:rmi:///jndi/rmi:// --jmxuser controlRole --jmxpassword abcd1234"
# Specify the queue manager URL for using "browse" option of sysv initscript
ACTIVEMQ_QUEUEMANAGERURL="--amqurl tcp://localhost:61616"

Save your changes to the configuration file and exit the editor.

Now, you must edit the conf/jmx.password and conf/jmx.access files. Use the sample data they provide in the comments immediately above the lines. Remember to use the values you specified (or left alone) int the --jmxuser and --jmxpassword of the ACTIVEMQ_SUNJMX_CONTROL configuration line above.

Ensure that these JMX access control files are readable by only the activemq user account!

sudo chmod 600 /opt/apache-activemq-5.5.0/conf/jmx.password
sudo chmod 600 /opt/apache-activemq-5.5.0/conf/jmx.access

Doing that enables the init script to connect to the locally running software via JMX, a management console. Without this configured correctly you're looking at issuing a shutdown command and seeing a ton of Java errors followed by thirty seconds (configurable) of timeout before the script finally issues a KILL on the process.

Now run the service

sudo /etc/init.d/activemq start

Then look in the /opt/activemq/data directory for the PID and log files. You can tail the log file to see what is happening:

sudo tail -f /opt/activemq/data/activemq.log

All Done!

The Active MQ broker should be running. You can test this in a variety of ways including using the telnet command to connect to the broker on 61616, the JMX port on 11099 or more simply by opening a browser connection to the HTTP management port: http://localhost:8161

Continue reading...

January 13, 2011

Installing Sun Java on Ubuntu

It can be easy to forget how to install the "real" Java on a Debian system. There is that one command which seems to trip many people up.

The Sun Java is not really "free' software and is therefore not in the normal Ubuntu repositories. Therefore it is necessary to edit the /etc/apt/sources.list file and un-comment the

vi /etc/apt/sources.list

Look for the 'partners' section and un-comment both of the relevant lines:

deb http://archive.canonical.com/ubuntu natty partner
deb-src http://archive.canonical.com/ubuntu natty partner

Now the Sun Java runtime is available for download and installation as normal:

sudo apt-get update
sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-jdk

Accept the license if you want the application installed. Press the tab key to move to the appropriate fields.

Now for the part many forget. Ubuntu Linux comes with update-java-alternatives utility to update all alternatives belonging to one runtime or development kit for the Java language. To select Sun's JVM as one provided in Ubuntu, enter the following command:

sudo update-java-alternatives -s java-6-sun

Run java -version to ensure that the correct version is being called.

$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

That is all there is to it. Basically five commands to enter and a little file editing and you are running the "official" Java in under 3 minutes.
Continue reading...

September 23, 2010

Rigor and Formality

Of all the engineering disciplines, Software Engineering seems to have the least amount of guiding scientific principles and universally accepted methods. It remains as much a psychological / sociological practice as it is technological. The reason for this stems from the fact that Software Engineering is still primarily a creative activity as opposed to a mathematical (i.e. formal) process.

Programming versus Engineering

It should be noted at this point that this is not a comparison of software programming to software engineering; these are two fundamentally different scopes of software practices. Software programming normally involves one or two developers fulfilling all the roles of architect, designer, coder, tester and maintainer to deploy a relatively specialized system with a narrow scope of deployment. Many popular methodologies exist to support this style of development including Agile and Extreme programming. Software Engineering involves a team (or multiple teams) of specialists working toward the creation of a complex system supporting the needs of a diverse set of users which is to be deployed in multiple configurations all executed in a predictable manner. Software Engineering environments produce multiple complex systems in a predictable manner.

Software programming is a more ad hoc practice suitable for specific types of projects such as prototypes, utilities or clearly (i.e. narrowly) scoped projects. Even the largest organizations harbor software programming environments particularly in the maintenance and evolution of established or legacy systems.

Software Engineering environments are found anywhere there are multiple stakeholders and technical resources must coordinate their efforts to achieve their goals. It is a more formal and scientific endeavor which can only be successfully performed with the formality and rigor of the other engineering disciplines such as physical and chemical engineering.

Guiding Creativity

Because software development is a creative activity, there is an inherent tendency toward informal ad hoc techniques in software specification, design and coding. While such development practices can, statistically speaking, be successful in some large, complex projects, the need for rigor and formality will become apparent over time. Eventually the teams members begin to burn-out, the projects become too large to properly manage with an informal style, deliverables begin to slip, requirements are skipped or misinterpreted, code debt is incurred and overall product quality suffers. Predictably executing on large-scale projects requires significant effort.

Small software development environments which start out with one or two programmers can often utilize software programming practices for the organizations initial projects. Once that organization grows, however, those same practices begin to generate more problems than they solve. While it may seem that those practices are speeding the development, the quality of that product begins to suffer. Coordination between the increased numbers of participants and stakeholders tends to overwhelm the team and less time is spent productively. Communicating all the needs and expectations becomes difficult and the variables of each project increase greatly making success more difficult to reproduce and failure more difficult to avoid. Code debt and software defects continues to increase until the code base becomes unmanageable. It begins to cost more to maintain and evolve the code and ultimately the margins begin to shrink as software productivity declines. This is when software programming must evolve into Software Engineering.

Software development is a creative activity but is must be practiced systematically and with discipline. Rigor is a necessary complement to creativity that increases confidence in the results of development activities. Creativity often leads to imprecision and inaccuracy and software development can tolerate neither. The informal approach to software development is contrary to good Software Engineering practice.

The Need For Rules

Software Engineering involves many people of differing skill-sets, goals and interests. Without set rules, each participant imposes his/her own interest on the project. When problems occur, they become difficult to resolve and often result in unproductive conflicts. Software development needs a set of rules which allow participants to divide the workload without losing track of the work to be performed.

The rigor of a software development process is the level of discipline the process exhibits often through governance; it is the rules which direct how the process is executed. With rigor, a process can carry on smoothly without hindrances but without it projects invariably stray into problems resulting in unreliable products, high costs, missed schedules and even project failure. Rigor helps to produce products with higher reliability, greater quality while controlling costs and meeting expectations. Of equal importance is rigor enables repeatability and allows teams to avoid problems experienced in past projects.

The cost of activities early in the projects life seems high at that point in time but is insignificant when compared to the costs incurred in later phases. Time spent in clarifying requirements is minuscule when compared to the cost of re-designing a product to accommodate a forgotten requirement. Consider building a system which is required to encrypt all data in transit and then trying to retrofit such encryption requirements into a existing system a year after it was released. All software development projects can benefit from some set of rules to follow to ensure important requirements are not missed or undervalued. Some level of rigor must be applied in requirements gathering and analysis to ensure success and to avoid future costs of issue remediation.

Setting and following process rules allows all participants to operate in a coordinated manner.


There are varying degrees of rigor from completely ad hoc to the highest level of formality. A formal practice is where software systems can be verified by mathematical laws. Automated testing and error removals are not only possible but one of the benefits of adopting formal rigor in software development. There is a branch of software engineering known as Formal Methods which researches the potential of applying formality to software development. While is is well debated in many classrooms, conferences and coffeehouses, practical application of formal methods has been limited.

An excellent example of formality can be found at NASA in the development of software for space flight. The Goddard Space Flight Center (GSFC) software process has produced products with near zero defects. It is a testament to the level of rigor exercised by GSPC software engineers.


Rigor one of the elements which separates software programming from Software Engineering. While software development is a creative process, it benefits from some level of rigor which governs how that creativity is applied. Some programming projects complete just fine with a low level of rigor, but to consistently execute software development with predictable and high quality results, software engineers use rigor to guide their activities.

Continue reading...

About This Blog

This is a low frequency blog on implementing SOA designs using message brokering. It is a list of practical tips developed over several years deploying service oriented systems for targeted and mass deployments in the telecommunications carrier and electric utility markets.

Recent Articles

Blog Archive

   Copyright © Steve Coté - All Rights Reserved.

Back to TOP