Installing BTSync on Odroid-C2 Armbian

The Odroid-C2 is a powerful little device. Great bang for the buck. With its Gigabit Ethernet port and Quadcore 64bit processor. It would seem like an ideal candidate to setup a cheap home backup system using BTSync.

One little snag, the Odroid-C2 being 64bit, is ahead of the pack (most if not all other singleboard's, including the Pi 3 are 32 bit still). So, when trying to follow the Official Instructions to install BTSync, I got this error:

W: Failed to fetch http://linux-packages.getsync.com/btsync/deb/dists/btsync/InRelease Unable to find expected entry 'non-free/binary-arm64/

Packages' in Release file (Wrong sources.list entry or malformed file)

Unfortunately, BtSync doesn't yet provide a Arm64 binary, and, since its not open-sourced, you can't try and compile one yourself either.

Not to worry. Armbian/Debian provides an easy enough way to install and use the 32 bit binaries and run them in your 64bit Armbian OS.

First we enable armhf multi-arch support in the package manager:

sudo dpkg --add-architecture armhf
sudo apt-get update

Then we fixup the /etc/apt/sources.list file to explicitly limit BtSync's repo to armhf architecture. If you followed the official instruction, then a line like this got added to /etc/apt/sources.list.

deb http://linux-packages.getsync.com/btsync/deb btsync non-free

 Change it to this:

deb [arch=armhf] http://linux-packages.getsync.com/btsync/deb btsync non-free

 Re-run apt-get update so package manager becomes aware of those changes:

sudo apt-get update

Now you can do everything else as per the official instructions. E.g.

sudo apt-get install btsync

References

• Debian Multiarch HOWTO 
• Official instructions to install BTSync on Linux

RabbitMq Hello-World with Eclipse and Maven

This blog post is based on the RabbitMQ Hello World Tutorial. You should read that first. I'll just show you how you can get that example up-and-running using Eclipse rather than on the command line. I'll also include the steps needed to install rabbitmq.

My Environment:

• RabbitMQ 3.3.4
• Spring Tool Suite 3.6.0 (But you can also use a plain Eclipse with m2e tooling installed)
• Ubuntu 12.04 LTS

Installing RabbitMQ

Download the deb package. Once its downloaded double-click it to open it in Ubuntu Software Center and install it. That's pretty much it. The message broker is now running with default configuration settings.

You can double check the message broker is running (or start it) like so:

sudo invoke-rc.d rabbitmq-server start

You should see something like this:

* Starting message broker rabbitmq server
* message broker already running

Other useful commands:

sudo invoke-rc.d rabbitmq-server stop
sudo invoke-rc.d rabbitmq-server status

Setting up an Eclipse Project

You'll need a version of Eclipse with M2E installed. I used Spring Tool Suite simply because I already had it installed, and it includes M2E.

Use the "New Maven Project" wizard to create a simple maven jar project. Then put the following stuff in its pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>kdvolder.pivotal.io</groupId>
    <artifactId>rabitmq-hello-world</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>rabitmq-hello-world</name>
    <description>rabitmq-hello-world</description>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                </configuration>
            </plugin>
        </plugins>
    </build>


    <dependencies>
        <dependency>
            <groupId>com.rabbitmq</groupId>
            <artifactId>amqp-client</artifactId>
            <version>3.3.4</version>
        </dependency>
    </dependencies>

</project>

The code from the tutorial can be used pretty much as is. Put it into your maven project's main source folder.

Running The Code

When you are done, you can run the two sample apps 'Send' and 'Recv' by right-clicking them in the Package Explorer and selecting  "Run As >> Java Application".


If you just want to get the code and not copy-paste it together yourself. It is on github.

 

Using RMI without the Registry

Introduction

I was looking for a way to have one JVM talk to a child process that is also a JVM. Ideally, I'd simply like to call methods on the objects in the child JVM without too much hassles. I thought that RMI seemed like the perfect solution after reading through this great RMI tutorial from sun.

Then I found an even better RMI tutorial which simplifies things a bit and works great if you only care about the case where you have both 'client' and 'server' processes running on the same host.  Moreover this tutorial does things in Eclipse, which is a boon for me, since that's what I work with every day.

There was just one little thing that bothered me about the setup of the second tutorial. It still requires the use of the RMI registry for the client to obtain a reference to the server object. This is a tad annoying, because it means we still have to enter some shell command to start this service on the machine running both processes.

Is the RMI registry really necessary?

The short answer is no.

A longer explanation is that the registry is only required to get the 'first' remote object reference from the server to the client. From that point forward the client can 'talk' to this remote object by calling methods. That way you can send over objects as parameters, get other objects back as results etc. In all of this the registry plays absolutely no part. I found an article that explains this very well. Although unfortunately it seems to have been written in times when we still needed to use the RMI stub compiler. Nevertheless, conceptually, the explanation seems still correct.

So essentially, all you need is some way to bootstrap the process and 'send over' that first object without using the registry. That leaves us with the question:

How do we 'bootstrap' RMI without the registry

Reading the article, and Googling around a bit I found that several people were asking similar questions. Several of them suggested using Java serialization but mostly I just found questions from people having problems with that and no real solutions that I could easily implement. The article above was one of the best, but unfortunately the crucial bit of source code that actually does "the magic trick" seems to be missing!

So I thought it would be hard... but as it turns out actually it is quite simple. All you need to do is serialize your first stub-object (the very same one the server would normally register in the registry) and save that to a file. The client and server both have to agree on where that file is supposed to be. But that isn't a big problem in my scenario where both processes are on the same machine, and one of the processes is actually started by the other. For example, the location can be passed as a system property.

To show how it is done, I'll show you exactly which bits of code in the Eclipse RMI Tutorial need to be changed.

In the server class 'ComputeEngineStarter' there is this bit of code that creates the remote server object and registers it with a local RMI registry. Change it like this:

@Override
    public void doCustomRmiHandling() {
        try {
            Compute engine = new ComputeEngine();
            Compute engineStub = (Compute)UnicastRemoteObject.exportObject(engine, 0);
            
            //CHANGED: The normal way, using registry:
            //Registry registry = LocateRegistry.getRegistry();
            //registry.rebind(Compute.SERVICE_NAME, engineStub);
            
            //Using a file instead
            ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(Compute.SERIALIZED_STUB_FILE));
            try {
             out.writeObject(engineStub);
            } finally {
             out.close();
            }
        }
        catch(Exception e) {
            e.printStackTrace();
        }

    }

In the client class 'StartComputeTaskPI', we make a change:

@Override
    public void doCustomRmiHandling() {
        try {
            //CHANGED: extracted to a method:
            Compute compute = getComputeServer();

            PI task = new PI(50);
            Number pi = compute.executeTask(task);
            System.out.println("computed pi: " + pi);
        }
        catch(Exception e) {
            e.printStackTrace();
        }

    }

    private Compute getComputeServer() throws NotBoundException, FileNotFoundException, IOException, ClassNotFoundException {
        //CHANGED: The 'normal' way using the registry:
        //Registry registry = LocateRegistry.getRegistry();
        //Compute compute = (Compute)registry.lookup(Compute.SERVICE_NAME);
        //return compute;

        //Reading from a file instead: 
 ObjectInputStream in = new ObjectInputStream(new FileInputStream(Compute.SERIALIZED_STUB_FILE));
 try {
    return (Compute) in.readObject();
 } finally  {
     in.close();
 }
    }

Ofcourse you also need to define the constant that defines where the shared file lives. I'll leave that bit to you. Pick a location that works on your machine and os (e.g. I used "/tmp/compute-stub").

That's it. Now all you need to do is run the server application, then run the client and you'll see it works. No need to start the rmi registry.

Final notes

I did read a few comments and questions by people around the web (google :-) who seemed to have tried something similar and seemed to not have gotten it working. My guess is that the reason it didn't work was because of some other RMI related problem. Maybe the system property to tell RMI about the code base was not correctly set, maybe the Java security manager was not set up correctly.

The advice there is, make sure you have something that works with the registry first. The great tutorial that I started with takes care of all those little details.  Once I verified it worked, I made my attempt to 'eliminate' the registry.

Source Code

This is a zip containing the three sample projects. You can import them easily into Eclipse using the "Import as Existing Projects" wizard.

Deploying Grails Apps from STS to Cloud

Next monday is Eclipse Demo camp. Since I am going to have to prepare something to demo, and since I decided its going  to be showing off how easy it is now, to deploy your Grails Apps from STS directly into Cloud Foundry...

I thought it would be useful to write something up at the same time as something that can be used as 'how to' tutorial.

Here goes...

Installing STS / Grails / Cloud Foundry

Let's start setting up the stuff we'll need to develop Grails apps in STS and to deploy them to the cloud. Below is a list of the things we'll be installing and which versions.

1. STS (2.7.0)
2. Groovy Eclipse (2.5.1)
3. Grails (1.3.7)
4. Grails Support for STS (2.7.0)
5. Cloudfoundry Support for STS (2.7.0)

All of the needed stuff should be installable from the STS 2.7.0 Dashboard.

So step 1 is getting the STS 2.7.0 release and installing it on your machine.
Once installed open it go to the Dashboard's extension page and install items 2..5 listed above.

Getting a CF account

I've already got one. Maybe you do too. But if you don't, you'll need to signup for one, it is free.

Creating a Test Application

We'll be using an extremely simple 'gTunes' application. So, let's start by creating an empty Grails App.

Menu: File >> New >> Grails Project

If you aren't already in the Grails perspective, you'll get asked if you want to switch to it. click 'Yes'.

The app we just created is already fully functional, albeit not very interesting. Anyway... before we add some stuff to it to make it more interesting, lets see if we can deploy it, as is, to Cloud Foundry.

Creating a CF Server in STS

When you first start STS in a new workspace, you will get an instance of tc Server automatically setup. You could try running the Grails app on that, but for this Demo, we're going to want to try Cloud Foundry instead. We'll have to configure a Cloud Foundry 'Server' in STS to make this possible.

Cloud Foundry isn't a 'Server' really, but a "Platform as a Service" (PaaS) for deploying Web applications directly to "The Cloud". Nevertheless, it is represented as a Server in the STS UI. So Right click in the servers view and...

Choose 'Cloud Foundry' as the type of server. Note the 'Server's host-name' is by default set to 'localhost'. This may seem odd and a little confusing. Just realize that CF isn't really a 'sever' and the value of this field is just ignored, so you don't need to change it.

Click next and enter your credentials, then click 'Finish'.

You should now have a CF Server in the server's view.

Cloud Foundry isn't a 'real' server but PaaS service, so many of the 'standard' functions for Servers don't apply to CF. For example, you can't 'Stop' or 'Start' Cloud Foundry. This is why you'll see most of the buttons in the Server's view disabled for Cloud Foundry.

We are already 'Connected' to the Cloud Foundry account we have just configured. This is indicated by the green triangle in the Cloud server icon.

However, when you exit and restart STS the next time, you will start out in a 'Disconnected State'. Instead of a green triangle you'll see a blue square:

You can always Connect/Disconnect to/from the CF account by right-clicking on the CF server and selecting Connect/Disconnect.

Deploying Grails App to CF

The STS-UI provides a few different ways to add or remove apps to the CF server. The easiest one is probably to Drag and Drop the app you want to deploy onto the CF server. After you drop your app onto Cloud Foundry, you'll be presented with a Wizard Dialog asking you to configure some basic properties of the deployed app.

That's it. The app is now running in the cloud... and it can be accessed at http://gtunes.cloudfoundry.com.

Of course the app isn't very interesting yet... It's just a welcome page with nothing on it. So... let's add something.

Modifying and Redeploying the App

Let's add a 'Song' domain class with a title and artist field. Right click on the 'Domain' node in the Project Explorer view and select 'New Domain Class'. Type the name of the Domain class and hit 'Finish'.

This will execute the Grails command "create-domain-class Song". The output of this command will be shown in the console view and the generated Song.groovy will be opened in the editor once the command finishes.

Let's add some data members to the Song class.

class Song {

    String title    //ADDED!
    String artist   //ADDED!

    static constraints = {
    }
}

Also let's create a controller for this domain class. Right click on the Song class in the Project Explorer and select "New Controller". The wizard that pops up will already have the name of the Song domain class filled in, so just click Finish.

Similar to the the 'New Domain Class' functionality, this executes the Grails command 'create-controller' and then opens up the generated controller class in the editor. We modify it slighly to use Grails's dynamic scaffolding to generate a fully functional web UI based on the domain class.

package gtunes

class SongController {
    def scaffold = Song // CHANGED
}

OK, now let's check the results of our work.

The changes we made won't be automatically propagated to CF. We need to 'Restart' our app to make the changes appear on the Cloud Foundry URL.

To redeploy a changed app right click on the app in the server's view and select 'Restart'.

When you restart the App, you will notice in the console view that a 'grails war' command is being executed to build a war file.

After the app got restarted, it may take some time before this change actually becomes 'live' at the Cloud Foundry URL. Keep reloading the URL, you can expect the following stages:

1. For some time you'll keep seeing the 'old content'.
2. The app goes offline and you'll get a VCAP 404 'not found' error.
3. The app comes back online serving the new content.

We now have a link to the newly added Song controller. Click on it to get a list of Songs, create new Songs etc.

It should be noted that you won't always see a grails war build happening. This is because the Grails STS tooling will try to just apply changes from the workspace incrementally to the last war build, instead of rebuilding the war file each time you make a change.

For example, if you just make some changes to an existing gsp file, domain class or controller, you will not see the war build. STS will simply repackage the result from the last war build with the changed files replaced in it.

As an example, we can add a "Genre" field to the Song domain class.

class Song {
    String title
    String artist
    String genre //Added
}

Now restart the app again, you won't see a war build, but the changes should eventually propagate to the CF URL.

Links / Further Reading

Cloud Foundry:

• http://www.cloudfoundry.com/ (signup for a free CF account)
• http://www.springsource.com/products/cloud
• http://blog.springsource.com/2011/04/12/launching-cloud-foundry/

SpringSource Tools Suite (STS)  = the “one stop shop” for all the tools used in this tutorial. Download and use it for free.

• http://www.springsource.com/developer/sts
• http://www.springsource.com/products/springsource-download-center