Sometimes bigger isn’t always better. If your dynamically-expanding virtual machine images are growing out of control, then here’s how to trim them back…

Background

I’m a big fan of VirtualBox, and use separate virtual machines (VMs) for the various separate bits and pieces I’ve got on the go (as I invariably end up messing something up, and can just trash the image and start again, without taking down whatever else it is I’m playing with at the time).

All my VMs use a dynamically expanding image for their hard drive, where you set the maximum size of the disk, but the system will only grow to fill that space if required. By setting this nice and high, I can be sure that the hard drive space is there if I need it, without taking space away unnecessarily from the rest of the system.

Unfortunately, whilst VirtualBox will dynamically expand the hard drive as it’s required, it won’t dynamically shrink it again if you free up space in the VM. This can be a problem, especially if, like me, the sum total of all those theoretical maximums exceeds the actual maximum capacity of the hard drive hosting all these VMs.

The good news is that you can shrink those images back down again. The bad news is that a lot of the guides on the internet are out-of-date, and woefully misleading. Here’s what I did to get the job done…

1. Free up space in the client machine

It’s a bit of an obvious first step, but you can only shrink down the client VM by the size of the available free space therein, so delete the files and uninstall the programs that you no longer need but are hogging your resources.

2. Zero out the free space

VirtualBox only knows that the space is really free if it’s been set to zero, and standard deletion won’t do this.

If it’s an Ubuntu VM

You’ll want to use zerofree:

• install with sudo aptitude install zerofree
• (if you don’t have aptitude, you can either use apt-get to install zerofree  (sudo apt-get install zerofree) or use apt-get to install aptitude (sudo apt-get install aptitude). I’d recommend getting hold of aptitude, as it does a great job of managing packages in Ubuntu)
• Reboot the machine (sudo shutdown -r now). During boot, hold down the left shift key. A menu will appear, you need to select “recovery mode”; this should be the second item in the list.
• You’ll get another menu, towards the bottom there should be the option to “Drop to root shell prompt”
• Run df and look for the mount point that’s that the biggest – this is where all your files are, and is the one we’ll need to run zerofree against. For the rest of this guide, we’ll assume it’s /dev/sda1
• The following three commands (thanks, VirtualBox forum!) stop background services that we can’t have running:
• service rsyslog stop
• service network-manager stop
• killall dhclient
• Once they’ve stopped, you can re-mount the partition as readonly (zerofree needs this)
• mount -n -o remount,ro -t ext3 /dev/sda1 /
• You can now run zerofree
• zerofree -v /dev/sda1
• Finally, shut down the VM
• shutdown -h now

If it’s a Windows VM

You’ll need to run sdelete; I’ve never done this, but there are instructions on that here:

• http://maketecheasier.com/shrink-your-virtualbox-vm/2009/04/06

3. Shrink the VM

Quite a lot of the online guides say that you’ll have to clone the hard drive image to shrink it, as VirtualBox 2.2 and above dropped support for compacting the image. This isn’t true, certainly not for version 4.0.4, and you can shrink the image in-place with the following command:

• VBoxManage modifyhd my.vdi –compact

That’s it!

With any luck, you’ll now have plenty of disk space to fill will equally useless tat…

jade-oo decouples behavioural logic from the underlying JADE system, allowing isolated testing of these critical components. Here’s how…

The current jade-oo example consists of two Agents sending messages to each other. One Agent, TimeRequestorAgent, wants to know what the time is, and the other Agent, TimeResponderAgent, responds with the current time.

Each Agent has one Behaviour. The TimeRequestorAgent has a jade-oo CyclicBehaviour that, every 12 seconds, sends a message requesting the time. The TimeResponderAgent has one jade-oo MessageReceiver Behaviour, which, every time a message is received, replies with the current time.

We want to test the execution of the business logic contained within the TimeResponderAgent. That logic isn’t within TimeResponderAgent itself, nor in the MessageReceiver Behaviour; it’s in the TellTheTime POJO that MessageReciver offloads its messages onto. Here’s the TellTheTime class in full:

package com.dantwining.jade.oo;

import jade.core.AID;
import jade.oo.core.behaviours.MessageReceiver;
import jade.oo.core.behaviours.Outbox;

public class TellTheTime implements MessageReceiver {

        private final Outbox outbox;

        public TellTheTime(Outbox outbox) {
                this.outbox = outbox;
        }

        @Override
        public void receive(String message, AID sender) {
                long currentTime = System.currentTimeMillis();
                outbox.send(currentTime, sender);
        }
}

In the real world, this class (and the classes that it in turn uses) are likely to be much more complicated. These are the classes that you want to test; the classes that add your functionality on top of the JADE framework.

Here’s the test for TellTheTime:

package com.dantwining.jade.oo;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
import jade.core.AID;

import org.junit.Test;

public class TellTheTimeTest {

        @Test
        public void shouldReturnCurrentTimeToRequestingAgent() {
                // Given standard construction...
                FakeOutbox fakeOutbox = new FakeOutbox();
                TellTheTime tellTheTime = new TellTheTime(fakeOutbox);
                AID requester = new AID("requester", AID.ISGUID);

                // ...when an incoming message is received...
                long timeBefore = System.currentTimeMillis();
                tellTheTime.receive(null, requester);
                long timeAfter = System.currentTimeMillis();

                // ...a reply should be sent to the requester, with an appropriate time.
                assertEquals(requester, fakeOutbox.getRecipient());

                long reportedTime = (Long) fakeOutbox.getMessage();
                assertTrue(timeBefore <= reportedTime);
                assertTrue(timeAfter >= reportedTime);
        }

}

Because MessageReceiver guarantees that your receive() method will only be called if a message is available, you don’t have to test for “message not present” behaviour. In fact, I can’t think of any other tests for this Behaviour, but please post a comment if you can.

Compare our TellTheTime code with a standard JADE Behaviour that performs the same task:

package com.dantwining.jade.oo;

import jade.core.behaviours.CyclicBehaviour;
import jade.lang.acl.ACLMessage;

import java.io.IOException;

public class TimeResponderJadeBehaviour extends CyclicBehaviour {

    @Override
    public void action() {
        ACLMessage message = myAgent.receive();

        if (message == null) {
            block();
            return;
        }

        long currentTime = System.currentTimeMillis();
        ACLMessage reply = message.createReply();
        try {
            reply.setContentObject(currentTime);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
        myAgent.send(reply);
    }
}

How can we test this Behaviour? We’d probably want tests that:

1. Ensure that no action is taken if no message is received.
2. Ensure that any reply is addressed to the Agent who asked for the time.
3. Ensure that the time sent is accurate/appropriate.

But how can we…

1. Control myAgent.receive() so that it does/doesn’t return a test message?
2. Capture the argument to myAgent.send() to that we can check its address?
3. Capture the argument to myAgent.send() to that we can check its contents?

In standard JADE, receive(), send() and block() are all hidden side-effects. In jade-oo we (a) expose Outbox and Block so that interactions with them are testable, and (b) encapsulate responsibility in the MessageReceiver so that client code is only invoked when a message is available for processing, and doesn’t know (or care) about any other states.

In JADE, an Agent has a set of Behaviours, and each Behaviour has an action() method. The Agent calls the action() method of each Behaviour in turn, and so the overall operation of the Agent is performed by each of its individual behaviours.

By default, an Agent will continue to call each of the action() methods of its behaviours, in turn, without pausing. Rather than looping forever at 100% CPU, Behaviours can call one of two block() methods, provided by the Behaviour base class. Calling block() from within the action() method tells the Agent to only call action() again if a message is received; and calling block(long timeout) tells the Agent to only call action() again if a message is received or timeout milliseconds elapses, whichever is sooner.

The problem

What happens if, within your action() method, you call block() then block(50)? What happens if you call block() right at the beginning of your action() method? How can you unit test that a certain set of of inputs will prompt a Behaviour to block()?

Hiding calls to block() within the action() method results in hidden side-effects that are difficult to reason about, and difficult to capture and test.

The jade-oo way

Rather than having a void action() method, jade-oo behaviours have a Block action() method. The behaviour then returns a Block object, which the platform then uses to determine whether to keep the behaviour active, or to leave the behaviour until a new message is received/the timeout has elapsed.

Here’s my Block class:

package jade.oo.core.behaviours.blocking;

import jade.core.behaviours.Behaviour;

public abstract class Block {
        public static Block NULL = new DontBlock();
        public static Block UNTIL_WOKEN = new BlockUntilWoken();
        public static Block UNTIL_WOKEN_OR_TIMEOUT(long timeout) {
                return new BlockWithTimeout(timeout);
        }
        public void doBlock(Behaviour behaviour) {
        }
}

Here’s one of the three implementations (note that the behaviour being passed in is the standard JADE Behaviour):

package jade.oo.core.behaviours.blocking;

import jade.core.behaviours.Behaviour;

class BlockUntilWoken extends Block {

        @Override
        public void doBlock(Behaviour behaviour) {
                behaviour.block();
        }

}

Here’s the modified method in the standard JADE Behaviour class (note that the original is abstract, and so any existing implementations will simply override this and retain their existing behaviour):

          /**
         * Runs the behaviour. This abstract method must be implemented by
         * <code>Behaviour</code>subclasses to perform ordinary behaviour duty. An
         * agent schedules its behaviours calling their <code>action()</code>
         * method; since all the behaviours belonging to the same agent are
         * scheduled cooperatively, this method <b>must not</b> enter in an endless
         * loop and should return as soon as possible to preserve agent
         * responsiveness. To split a long and slow task into smaller section,
         * recursive behaviour aggregation may be used.
         *
         * @see jade.core.behaviours.CompositeBehaviour
         */
        public void action() {
                Block blockAction = delegate.action();
                blockAction.doBlock(this);
        }

And here’s an example of its use, taken from my new TickerBehaviour (my only changes here are on the two return lines at the end):

        @Override
        public final Block action() {
                // Someone else may have stopped us in the meanwhile
                if (!finished) {
                        long blockTime = wakeupTime - System.currentTimeMillis();
                        if (blockTime <= 0) {
                                // Timeout is expired --> execute the user defined action and
                                // re-initialize wakeupTime
                                tickCount++;
                                onTick();
                                wakeupTime = System.currentTimeMillis() + period;
                                blockTime = period;
                        }
                        // Maybe this behaviour has been removed within the onTick() method
                        if (!finished) {
                                return Block.UNTIL_WOKEN_OR_TIMEOUT(blockTime);
                        }
                }
                return Block.NULL;
        }

Further enhancements

• I don’t like Block; it sounds like the Behaviour is stopping something else from processing, when really it’s doing the opposite, and freeing up CPU cycles for other behaviours to use.
• I’m not sure about having the static methods within the interface itself. I should probably have a Block interface with a doBlock(Behaviour behaviour) method, and a BlockFactory with the three static methods. Or something else?

I hope that any improvements I can make will be folded back into the main JADE code base. My general plan is to maintain backwards-compatibility though liberal use of deprecation, whilst adding an API that makes better use of OO, with a particular emphasis on unit testing (i.e. software written against my API should be very easy to test).

Well, that’s the overview; it’s probably time to write an article or two on what I’ve actually done so far…

Much in the same way as Microsoft’s correct use of fewer wasn’t enough to persuade me to rush out and buy Windows 7, I’m probably not going to rush out and buy Beyoncé’s latest album either. Although I guess I am publicly acknowledging the fact that I know the lyrics to at least one of her songs. Meh.

I’m fairly sure that I’m not going to do Ray’s talk justice here, so if you want to nip off and watch the video or flick through the slides then please do so. But in a nutshell, two of the things that Ray discusses are; applying the Model-View-Presenter pattern within GWT, and reusing GWT’s built-in EventManager class to provide an event bus that decouples both the GUI from the back-end, and bits of the GUI from each other.

Breaking out the gwitbus

The main reason for pulling the EventManager out of the core GWT library is so that I can use it as the event bus in my non-GWT apps. Because the EventManager and its associated classes are all pure Java, with no dependencies beyond core Java collections, we can just drop them straight into any Java app. Just like I’ve done in the Swing app that I’m working on at the moment.

I could just import the core GWT jar, but that’s over 5MB, which it a bit of an overkill for about seven classes (and I’m not even sure that four of those are required).

At some point in this post, I need to give credit to Matt, who pair-programmed with me on our recent GWT-based task, and is now working with me on our new gwitbus-enabled Swing app. It’ll just get confusing if I try to differentiate between the bits that I’ve done, the bits that he’s done, and the bits that we’ve done together, so I’ll just stick to the first-person-singular for now; but thanks for your help, and if you wanted to take all the credit, you should’ve written your own post and checked it into you own Google code project

How do I use the gwitbus?

I’m planning on putting together a really basic Swing app that demonstrates its usage, but to be honest everything you need to know can be divined either from the code, or from Ray’s slides.

Conceptually, the gwitbus is like any other event bus. It provides an abstract connection between disparate parts of the app; one part can fire events into the gwitbus, and another can listen for those events and react to them. Crucially, the part firing the event has no idea who will be listening, and the part listening has no idea who’s firing the events.

If “the gwitbus is like an other event bus”, then why should I use it?

Well, the most important thing is that you don’t roll your own. Almost everything you can do has already been done better by someone else. If you need an event bus, and your framework comes with an event bus, then feel free to use it. But if you don’t have one already, then why not use one that sits at the core of a proven, Google-backed technology?

Where can I get me a gwitbus?

gwitbus now has its very own project on google code. You can check it out from its subfolder in my subversion repository at http://gwitbus.googlecode.com/svn/trunk/, run the ant jar target, and get yourself a gwitbus.jar.

(If you’re browsing through the repository, don’t be fooled by the fact that there doesn’t appear to be any code in there at all; svn:externals pulls in the latest code straight from GWT)

I’ve already got a Hudson job building the latest version every time it’s updated. I hope to have Hudson push the latest release back onto Google Code, but I haven’t yet worked out how to do so without putting my credentials somewhere where they’ll be publicly visible. For now, I’m afraid that you’ll jut have to build it yourself.

The Problem

I wanted a full screen map. Like this.

But what I got was this.

It only happened when the page first opened. If I resized the window, or panned/zoomed the map, then the map redrew to fill the page.

It didn’t matter if I used GWT-OpenLayers (a Widget that wraps up the OpenLayers library) or just got at the OpenLayers javascript directly. Also, it didn’t matter which browser I used, they all drew the map in the top left-hand corner.

The Solution

The answer is to add a DeferredCommand, which updates the map once GWT has finished doing everything else. Here’s a cut-down example which uses a GWT-OpenLayers widget, but the fix works perfectly for standard OpenLayers too.

public void onModuleLoad() {

   ...

   final MapWidget mapWidget = new MapWidget("100%", "100%", config);

   ...

   mapWidget.getMap().setCenter(new LonLat(lon, lat), zoom);

   DeferredCommand.addCommand(new Command() {

      @Override

      public void execute() {

         mapWidget.getMap().updateSize();

      }

   });

}

You’re welcome to check out my onModuleLoad() method in full here.

If you’re using OpenLayers directly, you need to jump through a little extra hoop (or at least I did, there’s probably a much better way of doing it) in order to get at the javascript redraw method…

   DeferredCommand.addCommand(new Command() {

      @Override

      public void execute() {

         updateMapSize();

      }

      private native void updateMapSize() /*-{

         $wnd.map.updateSize();

      }-*/;

   });

}