One of the really powerful features of Virtual Box is that it lets you start VMs in a headless mode. You can connect to the VMs using RDP or just let them run in the background and do their job. The problem with running a lot of VMs in headless mode is trying to determine which VMs are running and when I want to shutdown the VM, I have to go to the command line and do a VBoxManage controlvm VM_NAME acpipowerbutton. This can get really tedious.

To simplify the most common interactions I do with my VMs, I built a simple Notification Area applet in Python. I started with this great tutorial that I found after doing some Google searches, Gnome Notification Area Application in Python. This is a great starting point for building applets for the Notification Area.

When I right click on my notification applet, I want it to bring up a popup menu with all of my VMs. I wrote the following Python function to list VirtualBox VMs:

def listVMs(type):
  f = os.popen('VBoxManage list ' + type)
  lines = f.readlines()
  vms = []
  for line in lines:
    vms.append(line[1:line.rfind('"')])
  f.close()
  return vms

VBoxManage list can list all kinds of interesting things in VirtualBox but I only care about vms to list all the VMs and runningvms to list all the running VMs. I then use these lists to populate the popup menu with options for shutting down running VMs and options for starting non-running VMs in normal mode or in headless mode.

When I click on my icon in the Notification Area, I want it to either start the VirtualBox Manager or focus the VirtualBox Manager window if it is already running. Starting the VirtualBox Manager is easy. Determining if the VirtualBox Manager is already running and focusing its window is much more difficult. I found wmctrl which allows me to focus windows based on their title and I’m able to leverage this in my applet.

The script I’m using in its entirety is available at vbox-notification-app.py.

• 1 Comment

I just got a brand new Lenovo ThinkPad W510 for work.  It’s a great machine.  Really fast.  Unfortunately, it hasn’t been suspending for me in Linux.  It starts to suspend and then fails.  It turns on the Linux module, XHCI, used for USB 3 is broken.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/522998

https://bugzilla.redhat.com/show_bug.cgi?id=623573

To remedy the problem, I just did:

sudo rmmod xhci_hcd

Fortunately, I don’t have any USB 3 devices.

• 0 Comments

I’ve been reading about Receive Packet Steering on Linux. I have heard anecdotal evidence that this can greatly improve performance. It made me wonder if you could improve performance even more by telling the kernel that you want the thread the processes the IO for a particular interface to run on the same CPU that is handling the interrupts for the interface.

Java doesn’t provide support for CPU/Thread affinity out of the box. Linux has the sched_setaffinity(2) that does this.  So, I wrote some JNI code to allow me to set a thread’s affinity mask for a particular CPU.  I’ve pushed this code out to GitHub.  I also implemented a CpuLocal class that is similar to ThreadLocal.  The build is targeted for 64-bit platforms and may require some tweaking to get it to run on yoru environment.

Unfortunately, I haven’t had much time (or proper resources) to benchmark my theories about combining CPU/thread affinity with receive packet steering but I thought I would push the code out anyway so that others can start playing with it.

• 2 Comments

I’ve been playing with Web Sockets using Google’s Chrome browser. Web Sockets, put simply, is a really nice way for a web application to talk to a remote server and allows the remote server to talk back. There are currently various ways of doing this with using Comet. But let’s be honest. Comet is a total hack. Web Sockets, on the other hand, is a very elegant solution.

I submitted a patch to the Netty project for supporting the Web Sockets protocol.

To demonstrate how to use this patch, I’ve created a little demo. This demo consists of a simple web page for sending data to the server using the Web Sockets API JavaScript API, and a simple Netty server for serving up the web page and handling the data send over the Web Socket protocol. You can download this demo from, http://people.apache.org/~mheath/websocketexample.zip. To compile it, you will need that latest version of Netty from Subversion and apply the patch I mentioned earlier.

• 2 Comments

I’ve been meaning to post these results for a while and with the Thanksgiving break here in the US, I have time to finally do it.

When I ran my my original comparison, both the tests and databases were running on the same host connecting over the loopback interface. Using the loopback interface is a good way to test but the performance characteristics of going over a real network are much different. So I ran the tests again connecting to a second host over a gigabit/second Ethernet network.

I’ve also updated my tests to use the latest versions of both MINA and Netty.

Not only did I run the tests again over a real network connection, but I also added results for using Postgresql as well as the results of using plain JDBC and using JDBC with a thread-pool. Each test executes 50 SELECT statements and each test was run 100 times. Very interesting results.

An astute observer would question why JDBC is so much slower than both ADBCJ/MINA or ADBCJ/Netty. The answer to that question is the fact that ADBCJ supports pipelining which increases the performance of executing multiple queries significantly.

Netty continues to amaze and MINA is still really slow. It’s unfortunate to see the slow progress of MINA. While MINA 2.0 still hasn’t been released, Netty releases happen on a regular basis. It’s true that I’m on the MINA PMC and I could help get a 2.0 release out the door but I just don’t have the time. And honestly, why would I want to contribute to MINA when Netty is making faster progress and is frankly a better framework?

• 5 Comments

Why is DataInputStream.read(byte[] b, int off, int len) declared final? Stupid. Stupid. Stupid.

• 0 Comments