Anyway, I needed a simple tool to project the screen of my HTC Hero device on my PC, for showing it to an audience. I found one such application, but wasn’t really satisfied with its functionality and because I didn’t want to step on someones toes by messing around and changing way to much of the code I went for my own solution. My primary objective was to ensure it was operational before next Sunday, when I will need it.

Here is how it looks like

It is a simple Java Swing application, delivered as an all-inclusive executable JAR file. Therefore, one can launch it simply by double-clicking on the JAR file, or run the following command

java -jar droidAtScreen-0.3.jar

The Droid@Screen JAR file can be found here (pls understand it is alpha software)

• droidAtScreen-03.jar

Source Code

The source code is open source and I have put all of it to my git repo at Codaset.

• Wiki page
• GIT repo

The project is built using Maven. Before you can compile, you need to install two Android JAR files to your Maven repo. It is the android.jar and the ddmlib.jar files. Use the mvn install-file command. The easiest to get the mvn syntax right is to try compile it and wait for Maven to point out how to run the install-file command.

Screen-Shots

Here are some more screen-shots.

Landscape mode

Scaled image

Multiple windows

Save screenshots

Setting the path to the ADB executable

The application relies upon the Android Debug Bridge (ADB) application, which will be started unless it’s already running. So the very first thing Droid@Screen does is to prompt for that path.

—-

I have given several courses over a broad spectrum. It has been in

• Erlang programming
• Threads-programming in C++
• Java fundamentals
• Java advanced
• Cloud Computing

Over Christmas/NewYear I started to learn Android programming, which is really fun.

The major theme of the speech was the paradox of at one hand we have seen a tremendous improvements of languages, tools and methodologies over the last quarter of a century , but on the other hand we haven’t seen the proportional improvement in application quality and development velocity.

Over the years I have been working in both small organizations and large organizations. Based on my own experience and observations it seems to me that the likelihood of project failure is direct proportional to the size of the organization. One explanation is, of course, that I have been particular unlucky in chosing the right kind of organization. However, my observations tend to be on par with what other old veterans admit over a beer or a cup of coffe.

The first half of the seminar describes briefly some the advances in languages, tools and methodology. That means, the affecting forces of improved software quality and development velocity. The rest of the seminar tries to analyze why, despite of the just mentioned improvements, projects still fail.

One source is the ongoing transformation of the consultancy market. The whole software industri is affected by this transition, even if a single company do not engage consultants. This transition, in turn, is a respons to the ongoing organizational optimizations large corporations exercises in order to achieve lean-and-mean cash flow.

A single consultant is a revenue unit and we can formulate its revenue as product of its utlization and the max revenue.

revenue-of-a-single-consultant

The utilization is a number in [0, 1] and captures in average the net time a consultant produces income. An emperical observation of the utilization (my), is that it is an approximate constant.

emperical-observation-1

Two other emperical observations state that the time and team size, is direct proportional to the likelihood that the hourly rate is the same as the market average.

emperical-observation-2

emperical-observation-3

This leads to we can re-formulate the consultancy equation to be a product of the utilization, the market average and the competence coefficient (kappa).

revenue-of-a-single-consultant-refined

Using this, we can formulate the revenue equation for the whole team as a product of the team size, market average, utilization and the team (average) competence.

the-consultancy-equation

Based on the consultancy equation, we can then formulate the obvious economic in-equality as the salary plus the cost contribution must be less than the team revenue. This revenue, in turn, is a linear function of the team competence.

the-law-of-gravity-for-consultancy-life

I refer to this equation as the Law of Gravity for the Consultancy Life. That means, in a short time frame it is impossible to adapt to changes in market fluctuations, as we have seen during the last year.

The consultancy buyers tend to devaluate, or ignore, the competence coefficient (kappa) and the seller naturally tend to overstate it.

competence-factor

The involved players perform different compensational strategies to lower the cost and circumvent the consultancy equation. The buyers goes elsewhere, using off-shoring to take advantage of lower salaries. The sellers, employ rookies to take advantage of of low salaries (called junior-shoring). An finally, the consultants themself in order to maintain competence-based salary improvement, has two options to choose between; job-hopping or career change.

compensational-strategies

Over time, this transforms the whole consultancy market. Let’s look at the food chain of the consultancy market.

the-food-chain-of-the-consultancy-market

At the top we have the traditional consultancy company that deliver a defined result (solution) for a defined amount of money. The trick in pricing, is of course to add some margin to account for unknowns. Based on this margin, the hourly rate might seem too high for many buyers. The hourly rate is a very concrete factor, but delivered quality on the other hand a very fluffy factor. The former is imminent before the project start, but the latter is only possible to measure towards the end of the project. Therefore, buyers tend to ignore the latter and goes for companies that offer lower hourly rates.

At the bottom of the food chain, we have the new kind of consultancy brokerage firms, that can offer low hourly rates because they have zero overhead costs for non-enganged personell (people on the bench).

Squeezed in between we have the former solutions delivering companies, that nowadays tries to survive with pure staffing business. However, in the long haul they cannot compete with pure brokerage companies.

The trend in the industry is clearly towards lower hourly rates and therefore towards brokerage consultancy companies. But how does that affect the long term software quality?

To understand that, we have to look at the effective business model of traditional and new consultancy companies. With the word effective, I mean what happens in the real and not what people say.

effective-business-model

When the business focus is on delivering results, the sales people says “we need to sell more projects” and the technical people responds with “sure, if we work smarter and faster using modern tools and languages, we can complete projects in short time“. On the other hand, if the effective business model is on delivering hours, the sales people says “sell more hours” and the technical people responds “ok, if we introduce more bugs we can stay longer at the same project“.

Of course, nobody ever tell you this, but as a technical consultant you feel this very concrete. For example, the sales people tell you that they have sold you for 1000 hours. Then you ask what you are supposed to do and you get an answer similar to “I don’t know and I don’t care, just sit on your ass the amount of time we have sold you for and try do look busy“.

So, what is the impact of competence development for the single consultant in these two opposing business models?

impact-of-competence-development

Clearly, for hour delivering businesses being a better software developer is counter productive. It is considered a problem if you complete the task in half of the time you have been sold for.

In order to understand how this affect the software quality over time, we need to get familiar with two components. The first is the collective project knowledge, which is composed of both formal (written) documentation and informal (invisible) knowledge. The problems of this are the accuracy of the former and the propagation of the latter. We refer to this as project knowledge transfer. However, knowledge transfer takes time and therefore steals time and concentration from software development.

The second component is the draining vs. contribution time for a single project member. Every new member need to acquire the collective project knowledge in order to contribute to project. Before that happens, the person is draining the project instead, measured in time and cost.

project-contribution-curve

The draining time is always a positve non-negative number and is affected by the amount of invisble but necessary project knowledge.  However, knowledge-level, experience and professional seniority is reversely proportional to the draining time.

What happens is that for a long term project, which typically is the case for large organizations, and if the staff turnover rate is too high, the average contribution time becomes too low. If the non-contribution period starts to take a significant portion of the project time, the project is gradually loosing its collective knowledge. At the end, “nobody has a clue“.

accumulated-project-knowledge

The sad fact is that individuals and organizations has opposing ambitions, both trying to get more bang for the bucks.

opposing-ambitions

In one direction goes the technological evolution with higher abstraction levels and more involvment required and therefore higher competence required. In the opposite direction goes, the organizational evolution with standardization and policies which requires low involment and therefore the tendency to completely ignore the competency level.

The net effect, can we all read abount in the news papers; a never ending series of failed software projects.

You can view the whole slide deck at SlideShare

Here a the slides PDF (in Swedish)

• Vad är Cloud Computing?
• Vad är Groovy och Grails?

I will repeat these seminars in Gothenburg on Thursday.

Tomorrow (Wednesday) I will give a company internal seminar regarding trends in software development.

Before summer I was looking intensively for a open source version of calendaring and contacts that allowed me to synch to a mobile phone. I tried eGroupware with Funambole client. But there were allways some part that didn’t work, whever I got something to work.

Now, when I’m on the move frequently I need a working solution for mobile mail/calendar/contacts that also works with a desktop client. Google mail wasn’t an option becuase they doesn’t seem to have a professional solution for a small-business.

As long as it comes to pure mail management using the postfix/dovecot/spam-assasin/postgray combo, it works flawlessly. But finding a decent (open source) calendar and contacts server, accessing them over HTTPS from a hotel room or via a mobile phone, is not possible.

Running a SOHO server(s) has its moments, when the broadband connection goes down, when the home assembled firewall crashes or just the cat plays with a cable that happens to be cord to the ADSL modem. Last summer (2008), the firewall crashed due to iover-heating. It was an old PC baught for my son when we were living in London 2001. The problem was, me and my wife was at the Canary Islands for another two weeks. After that I got some new hardware from a local computer store and it lasted for a year. The firewall software I’m using is Smoothwall, which used to be a very decent OS-based firewall. However, they haven’t upgraded the bundled drivers for many years, which results in it’s not able to install on modern hardware.

When the firewall crashed recently I bought a brand-new (cheap) PC, just to discover for the second time that Smoothwall doesn’t install on contemporary hardware. I wasn’t particulary tempted to build my own distribution with the appropriate drivers, at the same time I was cut-off from the net. So, I found a spare machine from 2004, which allowed installation of Smoothwall. But, as I said in the beginning of this post, I will not wait for this junk to crash, so I have migrated the mail handling elsewhere.

The next step will be to migrate the webs {www, blog, lib}.ribomation.com. I will write another post, when it’s done. Probably it will take some time, because I will be on the move for several weeks during September and October. Next week I will run a series of seminars on Cloud Computing, Groovy & Grails and trends in Application Development. The following weeks I will teach Erlang, Real-time Systems Programming in C++, more seminars and then more Erlang and RT++. It goes on like this until November. It’s fun and intensive.

The primes in [2..N]

An initial version sends the numbers [3..N] to the first sieve thread representing the prime number 2. Each seive thread receives a number and checks if it’s divisable with the prime number of the sieve. If not, the number is forward to the next sieve. If there is no next seive, it is created using the current number as its prime number. That means, we have a pipeline of sieve threads that grows with each prime number found. The initial version of the solution finds all prime numbers in the given interval [2..N]. When the generator has sent all numbers, it sends a ‘done’ marker, which is forwarded throughout the pipe and each sieve terminates.

Here are the relevant portions of the code (the full source code can be found at the end of this blog post)

generator(N, interval, Stats) ->
  Next = sieve_create(1, 0, 2, stats_create(Stats)),
  iterate(3, N, send_and_forget(Next));

send_and_forget(Next) ->
  fun
     (done)   -> Next ! {done, []}, done;
     (Number) -> Next ! Number
  end.

iterate(N, N, Send) ->
  Send(done);
iterate(Number, MaxNumber, Send) when Number < MaxNumber ->
  case Send(Number) of
    done   -> iterate(MaxNumber , MaxNumber, Send);
    Number -> iterate(Number + 1, MaxNumber, Send)
  end.

sieve_create(Ordinal, MaxOrdinal, Prime, Stats) ->
  spawn(?MODULE, sieve_init, [Ordinal, MaxOrdinal, Prime, stats_create(Stats)]).

sieve_init(Ordinal, MaxOrdinal, Prime, Stats) ->
  StatsNew = stats_print(Ordinal, Prime, Stats),
  sieve_loop(Ordinal, MaxOrdinal, Prime, none, StatsNew).

sieve_loop(Ordinal, MaxOrdinal, Prime, none, Stats) ->
  receive
    {done, PrimeNumbers}  ->
      generator ! {done, [Prime | PrimeNumbers]};
    Number when (Number rem Prime) == 0 ->
      sieve_loop(Ordinal, MaxOrdinal, Prime, none, Stats);
    Number when (Number rem Prime) /= 0 ->
      Next = sieve_create(Ordinal+1, MaxOrdinal, Number, Stats),
      sieve_loop(Ordinal, MaxOrdinal, Prime, Next, Stats)
  end;
sieve_loop(Ordinal, MaxOrdinal, Prime, Next, Stats) ->
  receive
    {done, PrimeNumbers} ->
      Next ! {done, [Prime | PrimeNumbers]};
    Number when (Number rem Prime) == 0 ->
      sieve_loop(Ordinal, MaxOrdinal, Prime, Next, Stats);
    Number when (Number rem Prime) /= 0  ->
      Next ! Number,
      sieve_loop(Ordinal, MaxOrdinal, Prime, Next, Stats)
  end.

The drawback of this solution from a concurrency point of view is that it does not create particular many concurrent threads. At the time the generator sends the done marker, the pipeline is still under construction. Here is snippet showing it in action

$ erl -noshell -pa target/beam -run prime exe 10000 interval stats
1) 2 [processes 1/1, messages 18/18]
2) 3 [processes 2/2, messages 31/31]
3) 5 [processes 3/3, messages 29/31]
4) 7 [processes 4/4, messages 31/31]
5) 11 [processes 5/5, messages 31/31]
. . .
38) 163 [processes 38/38, messages 23/31]
. . .
72) 359 [processes 72/72, messages 31/31]
73) 367 [processes 58/72, messages 31/31]
. . .
728) 5507 [processes 31/72, messages 31/120]
. .
1226) 9941 [processes 1/72, messages 4/349]
1227) 9949 [processes 1/72, messages 3/349]
1228) 9967 [processes 1/72, messages 2/349]
1229) 9973 [processes 1/72, messages 1/349]
Prime Numbers [2,3,5,7,11,13,17,...,9941,9949,9967,9973]
$

In this case, I’m computing the prime numbers in the interval [2..10000]. Each line shows the ordinal number, the prime number and some stats. The stats shows the actual and maximum number of threads created and the length of the input queue of each sieve. At most 72 concurrent threads are running at the same time and most of the time essentially fewer threads.

The first N primes

More interesting is generating the N first prime numbers, because it will create N threads as well. That means I can study the threading and messaging performance. Here are the missing portions of the program

run(N, Mode, Stats) ->
  register(generator, self()),
  generator(N, Mode, Stats),
  Result = receive
    {done, PrimeNumbers} -> lists:reverse(PrimeNumbers)
  end,
  unregister(generator),
  Result.

generator(N, count, Stats) ->
    Next = sieve_create(1, N, 2, stats_create(Stats)),
    iterate(3, infinity, send_and_receive(Next)).

send_and_receive(Next) ->
    fun
       (done)   -> done;
       (Number) ->
            receive
                done    -> Next ! {done, []}, done
                after 0 -> Next ! Number
            end
    end.

sieve_loop(MaxOrdinal, MaxOrdinal, Prime, none, Stats) ->
    receive
        {done, PrimeNumbers} ->
            generator ! {done, [Prime | PrimeNumbers]};
        _Number ->
            sieve_loop(MaxOrdinal, MaxOrdinal, Prime, none, Stats)
    end;

However, I decided to re-write the program to avoid the list reverse in run/3, but also to make the stats more accurate. I show you the relevant portions of the new version below. The complete source can be found at the end of this post.

generator_loop(Number, Next) ->
    receive
        done ->
            Next ! {done, self()},
            unregister(generator),
            receive
                {result, Primes, StatsLst} -> {Primes, StatsLst}
            end
        after 0 ->
            Next ! Number,
            generator_loop(Number + 1, Next)
    end.

sieve_create(Prime, Ordinal, MaxOrdinal, Verbose) ->
    print_progress(Prime, Ordinal, Verbose),
    check_if_last(Ordinal, MaxOrdinal),
    spawn(?MODULE, sieve_loop, [Prime, Ordinal, MaxOrdinal, none, Verbose, stats_create()]).

check_if_last(N, N) -> generator ! done;
check_if_last(N, M) when N < M -> ok.

sieve_loop(Prime, Ordinal, MaxOrdinal, Next, Verbose, Stats) when Ordinal < MaxOrdinal ->
    receive
        Number when (Number rem Prime) == 0 ->
            sieve_loop(Prime, Ordinal, MaxOrdinal, Next, Verbose, stats_update(Stats));

        Number when (Number rem Prime) /= 0 ->
            NextNew = case Next of
                none -> sieve_create(Number, Ordinal+1, MaxOrdinal, Verbose);
                Pid  -> Pid ! Number, Pid
            end,
            sieve_loop(Prime, Ordinal, MaxOrdinal, NextNew, Verbose, stats_update(Stats));

        {done, Prev} ->
            Next ! {done, self()},
            receive
                {result, Primes, StatsLst} ->
                    Prev ! {result, [Prime | Primes], [stats_id(Stats, Ordinal, Prime) | StatsLst]}
            end
    end;
sieve_loop(Prime, MaxOrdinal, MaxOrdinal, _Next, _Verbose, Stats) ->
    receive
        Number when is_integer(Number) ->
            sieve_loop(Prime, MaxOrdinal, MaxOrdinal, none, none, stats_update(Stats));

        {done, Prev} ->
            Prev ! {result, [Prime], [stats_id(Stats, MaxOrdinal, Prime)]}
    end.

When the last sieve is created (Ordinal == MaxOrdinal) it sends the done marker to the generator. The generator the sends its own PID to its next seive and each sieve forwards the done marker together with its PID. When the done marker hits the last seive, it creates the last item of the resulting prime number list and sends it to its predecessor. Each sieve prepends its own prime and finally the complete list of prime numbers arrives to the generator. Finally, we are done with the preludium of this blog post. Let’s study its execution.

Running the Erlang version

Here is a first run with the dedicated ‘N first primes’ version.

jens@spooky:~/workspace/Prime$ /usr/lib/erlang/bin/erl -pa target/beams/
Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2] [async-threads:0] [kernel-poll:false]

Eshell V5.6.5  (abort with ^G)
1> prime:run(10).
1) 2
2) 3
3) 5
4) 7
5) 11
6) 13
7) 17
8 ) 19
9) 23
10) 29
Elapsed time 0.002 secs
[2,3,5,7,11,13,17,19,23,29]
2> prime:run(1000).
1) 2
2) 3
3) 5
. . .
999) 7907
1000) 7919
Elapsed time 5.886 secs
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,
 79,83,89,97,101,103,107,109|...]
3>

Spawning 1000 threads in Erlang is a no-brainer and we can see it performs pretty good. The program also collects some statistics of each sieve input queue and writes it out to a CSV file. Here comes the interesting part

We can see that at most 147 messages was in the message queue of sieve(1,2), but in average the queue length is way more moderate, fluctuating around 10. Let’s do another round, this time with 10.000 threads, before starting the discussion.

$ erl -pa target/beams/
Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2] [async-threads:0] [kernel-poll:false]

Eshell V5.6.5  (abort with ^G)
1> prime:run(10000, no).
Elapsed time 272.172 secs
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,
 79,83,89,97,101,103,107,109|...]
2>
Here are the message queue stats:

Even this time we can see that the message queue length is very moderate. In both cases the first sieve receives the major hit of messages and after that for the rest of the pipeline, the queue length is around 10 or less.

If you knew the concurrency model of Erlang, but not its implementation, this is suspicious. Erlang messages are sent by asynchronous message passing, which means that a thread loops and sends an unbounded number of messages until the thread is put on hold for a while (i.e., it runs out of reduction ticks).

What we should have seen; is a large amount of messages in the beginning of the pipeline. However, that doesn’t happen because the Erlang runtime system takes care of the fine-tuning of its thread scheduling. A thread is allowed to perform a certain number of reductions (e.g. function calls and pattern matching) before it is put on hold and inserted last in the ready-queue. This queue contains all threads that do not wait for some condition, like a receive statement. So instead of running for a certain amount of time it runs for a certain number of operations. The consequence is paramount; a thread cannot send too many messages before the recipient has a chance to ‘receive’ them. In addition, the Erlang runtime system tries to level the send rate so the recipient’s message queue doesn’t get flooded. To fully understand this and fully appreciate it, let’s study the same program in Java.

The Java version

I will just show you fragments of the Java code. You can find all sources at the end of this post.

Class Sieve

public class Sieve extends Thread {
    public static int               maxOrdinal = 0;
    private int                     ordinal, prime;
    private Sieve                   next;
    private LinkedList<Integer>     numbersInput = new LinkedList<Integer>();
    private volatile boolean        running = true;

    public Sieve(int ordinal, int prime) {
        this.ordinal  = ordinal;
        this.prime    = prime;
        start();
    }

    public void run() {
        if (ordinal == maxOrdinal) {Generator.done();}

        int n;
        while ((n = getNumber()) > 0) {
            if (ordinal == maxOrdinal) continue;
            if (n % prime != 0) {
                if (next == null) {
                    next = new Sieve(ordinal+1, n);
                } else {
                    next.putNumber(n);
                }
            }
        }
        if (next != null) next.putNumber(0);
    }

    public synchronized void putNumber(int n) {
        if (n > 0) {
            numbersInput.addLast(n);
        } else {
            running = false;
        }
        notify();
    }

    private int getNumber() {
        int n;
        synchronized (this) {
            while (running && numbersInput.isEmpty()) {
                try{ wait(); }catch (InterruptedException e) {}
            }
            n = running ? numbersInput.removeFirst() : 0;
        }
        return n;
    }
}

Inside the run() method we recognizes the sieve algorithm. Java do have support for message passing, so we have to implement it. I’m using a linked-list and synchronized methods. The public putNumber() method is called by the predecessor and inserts a message last in the queue/list. The private getNumber() is used by the sieve loop to fetch the next number. If the input queue is empty, it waits until notify() is called in putNumber(). The last sieve calls the done() method of the generator, which sends ‘0′ to all sieves.

Class Generator

public class Generator extends Thread {
    private static volatile boolean     running = true;
    private Sieve                       next = new Sieve(1, 2);

    public void run() {
        for (int n = 3; running; ++n) {
            next.putNumber(n);
        }
        next.putNumber(0);
    }
    public static void done() {running = false;}
    //. . .
}

I have remove some code from the generator, but the important part is retained. In the run() method, the generator thread sends an unbounded sequence of numbers to its successor. When the last seive calls done() it breaks the loop and sends ‘0′. You might wonder why done() is not synchronized. That is because it’s exactly one thread that will call done() and it’s harmless to assign ‘running’ a new value.

Running the Java version

Let’s start with an easy one; the 100 first prime numbers.

$ java -cp target/classes/ Prime -y 0 -b 0 -n 100
1) 2
2) 3
3) 5
4) 7
. . .
75) 379
76) 383
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Thread-16" java.lang.OutOfMemoryError: Java heap space
	at java.lang.Integer.valueOf(Integer.java:601)
	at Sieve.putNumber(Sieve.java:56)
	at Sieve.run(Sieve.java:39)
$

Whoa!!! It crashed after just 76 threads! Can this be true? What is happening? I managed to run it to completion, when starting a second time.

$ java -cp target/classes/ Prime -y 0 -b 0 -n 100
1) 2
2) 3
. . .
99) 523
100) 541
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541]
Elapsed time: 35.872 secs
$

Hmmm, the Erlang version running up to 1000 sieves took 5 secs and the Java version running a just up to 100 threads took 35 secs. Let’s see what is going on in the Java program and the true side of asynchronous message passing - as it had been seen in Erlang if not its runtime system had been so helpful.

Five million (5,983,878) messages in the first sieve and in average 50,000 messages in each sieve’s message queue! We can clearly see why it’s so important that the Erlang runtime system manages and levels how many messages are permitted to be sent, to prevent it ending up in the situation our Java version is in.

Java is using native threads, which on my Ubuntu Linux machine means POSIX Threads (NPTL). The threads are scheduled using interrupt-driven preemptive scheduling, which means at a regular frequency a clock interrupt switches the currently executing thread. This can happen as a ‘bolt from the blue’.

To compare with cooperative scheduling, let’s introduce a helper class that invokes yield() and call it inside each loop of the generator and the sieve.

public class ThreadSwitcher {
  private long  count  = 0;
  private int    factor = 1;
  public ThreadSwitcher(int factor) {this.factor = factor;}
  public void yield() {
    if ((factor > 0) && (++count % factor) == 0) {
      Thread.yield();
    }
  }
}

If I run it with factor=10, it completes in 18 secs.

$ java -cp target/classes/ Prime -y 10 -b 0 -n 100
1) 2
2) 3
. . .
99) 523
100) 541
[2, 3, 5, 7, 11, 13, ..., 523, 541]
Elapsed time: 18.495 secs

If I decrease the factor=1, meaning a switch after each round, we get even better figures.

$ java -cp target/classes/ Prime -y 1 -b 0 -n 100
1) 2
2) 3
. . .
98) 521
99) 523
100) 541
[2, 3, 5, 7, ...,521, 523, 541]
Elapsed time: 7.467 secs

Now, look at the messages stats below. Much better numbers, although not as good as Erlang.

Is there anything else we can do? Yes, we can change the message sending semantics into a blocked (synchronous) implementation. I took the liberty to realize synchronous message passing in the Java program. You can find the sources at the end of this blog post. Now, running it without yield, but with a max length of each message queue of 100 gives this output.

jens@spooky:~/workspace/PrimeJava$ java -cp target/classes/ Prime -y 0 -b 100 -n 100
1) 2
2) 3
3) 5
. . .
98) 521
99) 523
100) 541
[2, 3, 5, 7, 11, ..., 523, 541]
Elapsed time: 0.455 secs

Yiiiha, Java rocks!. Looking at the message stats below shows something of a déjà-vu. Where have I seen numbers like this before? Hmm, let’s see. Aha, now I remember; when running the Erlang version.

OK, time to get serious again. I became curious about how the performance varies with the settings of the yield-factor (y) and the bound-buffer factor (b). Here is a table showing the elapsed time of 1000 sieve threads, as a function of some values of y and b.

It’s quite stunning to see that the elapsed time ranges from 93 seconds down to 4, just by changing how often the thread switches and capping the message queue length. In this case, we can see that the buffer-length contributes most and we can draw the conclusion that synchronous sending with buffer length 1 performes best. This is often namned rendezvous.

After running the series above using the Java version, I switched back to the Erlang version for comparison. Here are two runs with 1000 and 10,000 threads. Additional comments are superfluous.

$ erl -pa target/beams/ -noshell -run prime exe 1000 no
Elapsed time 2.213 secs
$ erl -pa target/beams/ -noshell -run prime exe 10000 no
Elapsed time 211.147 secs

The Java version still has a long way to go, when it comes to the number of threads. Above 1000 threads it starts to struggle. Running with 5000 threads takes 350 seconds and with 7500 threads it takes 852 seconds.

Some other day I will re-implement the program in C++ using pthreads and compare with both the Java and Erlang versions. Perhaps that will happen when I am teaching realtime systems programming in C++ on Linux in September for Ericsson in Gothenburg. You bet, I will be using the prime number pipeline as an exercise there too.

Source Code

• SVN project directory
• Erlang sources
• Java sources

Final words

This Erlang version is part of the exercises for a course in Erlang Basics I have been developing during the last couple of weeks. My Erlang course is marketed by Informator in Sweden and for a start intended for Ericsson. If you are interested in attending the course, please don’t hesitate to contact Informator.

A Little Bit of Theory

Critical Section

A critical section referrers to the code section executed to operate on shared data. Shared data is some state that can be accesses by several threads concurrently. The conditions required for a critical section problem to occur are

1. A non-atomic mutating operation. That means an operation consisting of the primitives READ/MODIFY/WRITE and they are not executed as one single indivisable operation.
2. Concurrent threads performing the operation.
3. Interruption of the threads somewhere within the operation. That means, one thread currently performing the operation is suspended and another starts and completes the operation, before the first thread are allowed to proceed.

Mutex Synchronization

In order to solve the problem (above) one has to violate at least of the conditions. The standard way of doing that is the realization of so called mutual exclusive access to the code section. This is normally solved using some form of lock. Java has a keyword synchronized, which behind the scenes uses POSIX mutex_lock()/unlock() on POSIX compliant systems such as Linux.

The Demo Problem

Consider a back account with multiple updaters performing depositions and withdrawals (yes, this is a classical ;-)

We start the system with 1 account of balance 0, U updaters which all performs 2N updates. First they deposit 100 (choose your currency here) N times and then withdraws 100 N times. The resulting balance should of-course be 0.

Erlang Implementation

Account

Let’s start with the Erlang implementation of the account. The account is represented as a thread (process in Erlang’s parlance).The create function starts a new thread which executes the account body function. The body waits for any of a set of messages. A message is sent using rendezvous (blocking/synchronous) realized using the functions send/2, recv/0 and reply/2.

account_create() ->
    {account, spawn(?MODULE, account_body, [0])}.

account_body(Balance) ->
    case recv() of
        {From, done} ->
            reply(Balance, From),
            done;
        {From, get} ->
            reply(Balance, From),
            account_body(Balance);
        {From, {set, Value}} ->
            BalanceNew = Value,
            reply(BalanceNew, From),
            account_body(BalanceNew);
        _ ->
            account_body(Balance)
    end.

account_get(Account)           -> send(get, Account).
account_set(Account, Value)    -> send({set,Value}, Account).
account_destroy(Account)       -> send(done, Account).

Updater

An updater performs all of its operations and then terminates, notifying the bank about its ‘departure’.

updater_create(Id, Account, NumUpdates, RunMode) ->
    {updater, Id, spawn(?MODULE, updater_body, [Id, Account, NumUpdates, RunMode])}.

updater_body(Id, Account, NumUpdates, RunMode) ->
    io:format("Updater-~w: started~n", [Id]),
    repeat(NumUpdates, fun() -> account_update(Account, +100, RunMode) end),
    repeat(NumUpdates, fun() -> account_update(Account, -100, RunMode) end),
    bank ! {updater, Id},
    io:format("Updater-~w: terminated~n", [Id]).

account_update(Account, Value, unsafe) ->
    Balance    = account_get(Account),  %READ
    BalanceNew = Balance + Value,       %MODIFY
    account_set(Account, BalanceNew);   %WRITE

The updater body uses a helper function repeat/2 that takes a positive number and a closure as arguments. The closure performs one function call account_update/3, which is the key to this blog post. The  last parameter is the mode of operation. As you can see, currently I only show you the unsafe mode. First it calls get/1 to READ the balance value, then it MODIFY the value and finally it WRITE the value back using set/2, which sends the new balance value to the account thread. Both get/1 and set/2 are rendezvous functions. One might say that a rendezvous creates a mutex operation.

Helpers

Let’s quickly show the helper functions, to get them out of the picture.

send(Msg, {_,To}) ->
    To ! {msg, self(), Msg},
    receive
        {reply, To, Result} -> Result
    end.

recv() ->
    receive
        {msg, From, Msg} -> {From, Msg}
    end.

reply(Msg, To) ->
    To ! {reply, self(), Msg}.

repeat(0, _Task) ->
    ok;
repeat(N, Task) when N > 0 ->
    Task(),
    repeat(N-1, Task).

Bank

Finally, here is the main function of the bank, that setups the system, runs it and tear it down again.

bank(NumThreads, NumUpdates, RunMode) ->
    io:format("Running the bank in ~w mode, with ~w updaters, performing 2*~w updates each~n",
              [RunMode, NumThreads, NumUpdates]),
    register(bank, self()),
    Account  = account_create(),
    Updaters = updater_create_all(NumThreads, Account, NumUpdates, RunMode),
    updater_wait_all(Updaters),
    Balance  = account_destroy(Account),
    unregister(bank),
    io:format("Final balance = ~w~n", [Balance]).

updater_create_all(NumThreads, Account, NumUpdates, RunMode) ->
    [updater_create(Id, Account, NumUpdates, RunMode) || Id <- lists:seq(1, NumThreads)].

updater_wait_all([]) ->
    ok;
updater_wait_all(Updaters) ->
    receive
        {updater, Id} ->
            updater_wait_all( lists:keydelete(Id, 2, Updaters) )
    end.

As you can see, the bank first creates the (single) account (object) and then all the updater (threads). The updaters are created using list comprehension, which is sort of a for-loop for functional languages. To the right, it first generates a list of integers (1..N) which is then used as a loop variable for the expression to the left which creates a new updater for each value of Id. After that, the bank waits for all updaters to finish. This is performed using the Erlang equivalent of a join-loop. It waits for a {updater,Id} message, removes it from the list of updaters and breaks the loop when the list is empty. The last task the bank performs before it closes, is destroying the account and reading its final balance value. This value is then printed to the console.

The bank module exports two public functions, run/3 and exe/1. The former performs some type checking and than invokes bank/3. The latter is used as the entry point when invoking the program from the console. I do not show them here, but you can find the complete code last in this post.

Execution

Time for the fun part; running the bank. Below you can find a couple of runs with the same parameter settings.

Unsafe Mode

$ erl -noshell -pa target/beams -run bank exe 5 10000 unsafe
Running the bank in unsafe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-1: terminated
Updater-2: terminated
Updater-4: terminated
Updater-5: terminated
Updater-3: terminated
Final balance = -907300
$ erl -noshell -pa target/beams -run bank exe 5 10000 unsafe
Running the bank in unsafe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-4: terminated
Updater-3: terminated
Updater-2: terminated
Updater-5: terminated
Updater-1: terminated
Final balance = 343800
$ erl -noshell -pa target/beams -run bank exe 5 10000 unsafe
Running the bank in unsafe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-5: terminated
Updater-4: terminated
Updater-3: terminated
Updater-1: terminated
Updater-2: terminated
Final balance = 436800
$

Pretty interesting, hu? Why is this happening? To understand this fully, we must return back to the theory at the top of this blog post. We can see that condition 1 is satisfied, because we perform the READ/MODIFY/WRITE operation in separate steps. Conditions 2 is trivially satisfied as well. How about number 3?

A few words about scheduling

Erlang threads are scheduled using what is referred to as runtime driven cooperative scheduling. Cooperative scheduling means that some party (the user or the  runtime system) switch threads at (hopefully) well-chosen points in the execution. The opposite is interrupt-driven preemptive scheduling, where a thread switch literally happens as a “bolt from a clear sky”. Very close to this form of scheduling is multi-core/cpu execution, which shows the same characteristics.This is main reason for introducing atomic locks in computer systems. A language based on cooperative scheduling, such as Erlang, can choose wisely where to switch threads.

In a language based on interrupt-driven scheduling, a thread is allowed to run for at most a fixed time period. There is a clock interrupt that fires at equiv-distant time steps. There is no such thing in Erlang. Instead a thread is allowed to invoke functions a certain amount of times. (To be more precise, N number of reductions, where N typically is 1000-2000).

Because the Erlang system has no understanding about the meaning of our account_update/3 function, it can (and does) switch the updater thread anywhere between each function/reduction within account_update/3, as soon as the thread as used up its current share of reductions.

Safe Mode

Now, when we understand why the problem arises we can move ahead and fix it. There is no such thing as a mutex lock in Erlang (although you can implement a thread type that acts as one), so we have to stick to the (obvious) solution of moving the READ/MODIFY/WRITE logic into the target thread. The account thread receives a message and performs one operation fully, before it moves on and serves the next message. This is our mutex. Below I show the missing code snippets.

account_update(Account, Value, safe) ->
    account_update(Account, Value).

account_update(Account, Value) -> send({update,Value}, Account).

account_body(Balance) ->
    case recv() of
        %. . .
        {From, {update, Value}} ->
            BalanceNew = Balance + Value,
            reply(BalanceNew, From),
            account_body(BalanceNew);
        %. . .
    end.

The ’safe’ version of account_update/3 invokes a new method (account_update/2) which sends the update mesage along with the value to the account thread. Within the account object/thread it now performs the operation in an atomic way, because nothing can interrupt its sequence of operations. Even if the account thread is suspended because it runs out of reduction ticks, no new operations will be started until the account resumes and completes the begun update operation. Nuff talk, let’s see it in action.

$ erl -noshell -pa target/beams -run bank exe 5 10000 safe
Running the bank in safe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-3: terminated
Updater-2: terminated
Updater-5: terminated
Updater-1: terminated
Updater-4: terminated
Final balance = 0
$ erl -noshell -pa target/beams -run bank exe 5 10000 safe
Running the bank in safe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-1: terminated
Updater-2: terminated
Updater-5: terminated
Updater-4: terminated
Updater-3: terminated
Final balance = 0
$ erl -noshell -pa target/beams -run bank exe 5 10000 safe
Running the bank in safe mode, with 5 updaters, performing 2*10000 updates each
Updater-1: started
Updater-2: started
Updater-3: started
Updater-4: started
Updater-5: started
Updater-4: terminated
Updater-1: terminated
Updater-3: terminated
Updater-5: terminated
Updater-2: terminated
Final balance = 0
$

Well, this is not a proof. But even running with hundreds of updaters doing millions of updates we will end up with the final balance = 0.

$ erl -noshell -pa target/beams -run bank exe 100 1000000 safe
Running the bank in safe mode, with 100 updaters, performing 2*1000000 updates each
Updater-1: started
Updater-2: started
...
Updater-99: started
Updater-100: started
Updater-7: terminated
Updater-29: terminated
Updater-90: terminated
...
Updater-16: terminated
Final balance = 0
$

Source Code

You will find a link to the source code below.

• bank.erl

Compile it at the command line with

$ erlc bank.erl

or start the Erlang shell and compile/run it there

$ erl
1> c(bank).

Run it from the command line with

erl -noshell -run bank exe 10 1000 unsafe

Where 10 updaters are started doing 2*1000 updates each all in ‘unsafe’ mode. Or, run it inside the Erlang shell with

2> bank:run(10, 1000, unsafe).

Final words

This Erlang demo program is part of the course ware for a course in Erlang Basics I have been developing during the last couple of weeks. My Erlang course is marketed by Informator in Sweden and for a start intended for Ericsson.

If you are interested in attending the course, please don’t hesitate to contact Informator.

Back in the late 80’s and beginning of the 90s I spent some time with Joe and the other guys around Erlang. I wasn’t an Erlang advocate myself, rather the oppsite and we had several debates regarding object-orientation versus process-orientation. I belonged to the C++ camp. Anyway it was fun and I became interested in the language.

At this time I had just started as an assistant professor teaching real-time systems programming at Royal Inst of Technology (KTH). At first, I was looking at Ada as the teaching language to use. However, the compiler license alone exceeded my course budget. Instead I found Concurrent C, which was a hybrid languge provided a superset of Ada’s message passing mechanism on top of ordinary C. As a companion to Concurrent C, I selected Erlang, which allowed me to illustrate both different solutions but also common design patterns in the field of concurrent programming. At this time when I started with academic education in Erlang I was the first in the world ;-) Well, enough talk about me.

What I really would like to draw to your attention is the organizational environment of the Erlang team. Erlang started as a research project in concurrent language design using logic programming languages as the basis. Prolog was the primary choice, however it was rather a rapid implementation language for various design ideas. In the beginning of the 90s, Ericsson was involved in a large project intended to be the future and replacement of AXE-10, which was the major revenue machine since the 70s. The project was named AXE-N and it focused on C++ and object-orientation from the language point of view. In this context, a semi-functional and concurrent language as Erlang, was simply as plugging a square into a round hole. So Erlang was sort of persona non-grata. During this time period nobody outside the Erlang team cared about the language and they were free to do almost anything they wanted, such as building up a user base outside Ericsson.

However, AXE-N had a lot of wrong premisses and soon things started to crack. I was a supervisor for several MSc thesis projects at the time, and acquired some technical insights, which convinced me that this couldn’t end happily. In 1995, AXE-N project finally collapsed and a lot of money had been wasted. One immediate conclusion was that it must be something wrong with C++ and it became banned. The aftermath of that ban can still be felt here and there within Ericsson.

Now, Erlang became reconsidered and selected as the primary language for the resurrected AXE-N project. One consequence was that Erlang now was considered a company assest and the external user base just an unconvenience. On the flip side was the team got heavily funded and they could grow the team several times the original size. It was during these years the Erlang library OTP was formed. In many respects, this was a fruitful time period of Erlang.

However, nothing lasts forever. In 1998, the halcyon days was over. Well, the year started with great achievement. They demonstrated a GPRS system at the GSM World Congress and at CeBIT. But some fractions within Ericsson didn’t like the idea of a symbolic, functional and concurrent language. During spring 1998, they had mobilized enough organizational power to issue an ‘anathema’ of Erlang.

This couldn’t and cannot be described without using the word ‘catastrophe’. The team was devastated and became disillusioned. People started to drop off. During the fall of that year a plan took form of resistance. Step one of the plan was to convince the organization that Erlang could be released as open source.

On 2 December 1998, Erlang was announced to be open source. A few days after, the whole Erlang team resigned and went to the newly created company Bluetail.

Bluetail, was initially a great success. But they couldn’t sustain the dot gone crash. Bluetail was first acquired by Alteon Web Systems and six days later that company was acquired by Nortel Networks. One of the major competitors of Ericsson. Shortly after, Nortel became a victim of the telco crash and most of the work force of former Bluetail was fired.

Since these turbulent days, Erlang has slowly raised from the ashes primarily as an open source project. Recently it has gained a lot of attention when people realized that there are some impressive Erlang applications out there. Such as the chat system of Facebook, the SimpleDB of Amazon WebServices (AWS), several financial systems such as Kreditor. A good overview of the state of the art usage of Erlang is the recent London conference. The master himself (Joe) gave a talk about Erlang in retrospect.

In summary, the life of Erlang has been a real roller-coaster. Now let’s go back in time to the early years of Erlang. At the same time Erlang was cooking in the lab of Ericsson (Ellemtel in Älvsjö, south of Stockholm), another language was cooking outside Standford University. Its name was -at that time- Oak. Oak was from the beginning supported by its hosting company. However, it didn’t reached its objective and was terminated in 1994. During the termination party one member demonstrated a demo of a web browser that could load Oak programs dynamically and make the “dead” web page alive. This was a turning point and the project resurrected to investigate how to best utilize the new program form called applet. The language changed name to -I’m convinced you’ve already guessed it- Java. The rest is what is frequently called ‘history’.

Now, compare these two languages. They were created more or less at the same time. Erlang had a head start. Both are dynamic. Both has built-in support for concurrency, although comming from different angles. Both are designed with fault-tolerance in mind. Both has support for dynamic code replacement.

Erlang failed to reach the masses and Java succeeded. One might argue that the world wasn’t ready for functional programming in the mid-90s and the step from C++ to Java was a very smooth step to take. This is indeed a fair standpoint.

On the other hand, Java was all the time treated as a loving child by its hosting company (Sun), but Erlang as an unwanted child by Ericsson. I’m convinced this is the key explanation why we are not programming E2EE applications today. What a pity.

A final word; you might wonder where comes my recent interest in Erlang from. The reason is I’m about to start develop a course in Basic Erlang for Informator intended for Ericsson. After 20 years, the loop is closed.

The tool Wily provided was named Introscope and was the first tool in its market segment when it started in 1999 and was the market leader all the time. One of my key missions was developing (hacking) numerous extensions for Introscope based on customer requests or my own observation of what I though the customers (or we professional consultants) needed.

As part of my re-launch of Ribomation as an independent consultant I have partnered with CA-Wily to partly do what I once did for Wily. Wily Technology was later acquired by CA. During this spring I have helped a governmental institution in Northen Sweden with a roll-out of Introscope as a monitoring solution for their Java systems.

One specific task was to enable alert integration with Tivoli. Back at the Wily era, I wrote an alert action extension for OpenView integration. In this case, I decided to make the extension more general and versatile, ant not tied to any specific SMC tool. The end-result is now released as open source and can be found here: SMC AlertAction.

Now have I started to take care of its new home. From now on you can find all RiboUtils at lib.ribomation.com. The starting page is extremely lame, but it show the links to the directory of the maven generated docs, the maven repo and the subversion repo.

What remains to do, is regenerating all maven docs updating the page links and import the sources into subversion. This is something I will do gradually, hrm…, some rainy day.

You can watch the video from the Stockholm event. The speech language is in Swedish and the length is around one and a half hour. The video format is Adobe Flash, so you need a proper flash-plugin.

• Watch the video (requires Adobe Flash plugin)
• Read the presentation slides (PDF)
• Register for the course “Cloud Computing i praktiken, 3 dgr”

One method of reading is input is decompressing GZIP:ed files. Java has built-in support for reading gzipped stream using GZIPInputStream. However, Hadoop ships with its own implementation that uses native libraries for efficiency.

I was curious about how much faster the native Hadoop variant was compared with the Vanilla version, so I wrote a small test. The result turned out to be a surprise:

May 6, 2009 10:56:47 PM org.apache.hadoop.util.NativeCodeLoader <clinit>
INFO: Loaded the native-hadoop library
May 6, 2009 10:56:47 PM org.apache.hadoop.io.compress.zlib.ZlibFactory <clinit>
INFO: Successfully loaded & initialized native-zlib library
May 6, 2009 10:56:47 PM org.apache.hadoop.io.compress.CodecPool getDecompressor
INFO: Got brand-new decompressor
Time of Hadoop  decompressor running 'small' job = 0:00:01.684 (1.684 ms/file)
Time of Hadoop  decompressor running 'large' job = 0:00:10.074 (1007.400 ms/file)
Time of Vanilla decompressor running 'small' job = 0:00:01.340 (1.340 ms/file)
Time of Vanilla decompressor running 'large' job = 0:00:10.094 (1009.400 ms/file)
Hadoop vs. Vanilla [small]: 125.67%
Hadoop vs. Vanilla [large]: 99.80%

For small GZ files (KB), the native version was slower and for moderately sized files (MB) the difference was negligible.

I’m running the test on a 1.67GHz dual core laptop with 2GB RAM and Ubuntu 9.04 64-bit. The ‘java.library.path’ points to the ‘hadoop/lib/native/Linux-amd64-64′ directory, which is needed so the JVM can pick up the correct library.

If you want to replicate the test, I have enclosed the test class below

package com.ribomation.weatherstats.computeTemperatures;

import org.junit.Test;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.assertThat;
import org.apache.commons.io.IOUtils;
import org.apache.commons.lang.time.StopWatch;
import org.apache.hadoop.io.compress.*;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;

import java.io.InputStream;
import java.io.IOException;
import java.util.zip.GZIPInputStream;
import java.util.List;

/**
 * Compares the built-in Java GZip uncompress with Hadoop's ditto.
 * <p/>
 * User: jens
 * Date: May 6, 2009  9:13:32 PM
 */
public class UncompressingComparativeTest {
    private String  sampleSmallFile = "/sample-file-KB.gz";
    private String  sampleLargeFile = "/sample-file-MB.gz";
    private int     numRunsSmall    = 1000;
    private int     numRunsLarge    = 10;

    @Test
    public void test_run() throws IOException {
        UncompressStreamCreator hadoop  = new HadoopUncompressStreamCreator();
        UncompressStreamCreator vanilla = new VanillaUncompressStreamCreator();

        long hadoopSmall = runTest(hadoop, sampleSmallFile, numRunsSmall, "small");
        long hadoopLarge = runTest(hadoop, sampleLargeFile, numRunsLarge, "large");

        long vanillaSmall = runTest(vanilla, sampleSmallFile, numRunsSmall, "small");
        long vanillaLarge = runTest(vanilla, sampleLargeFile, numRunsLarge, "large");

        System.out.printf("Hadoop vs. Vanilla [small]: %.2f%% %n", 100.0 * hadoopSmall / vanillaSmall);
        System.out.printf("Hadoop vs. Vanilla [large]: %.2f%% %n", 100.0 * hadoopLarge / vanillaLarge);
    }

    private long runTest(UncompressStreamCreator c, String file, int numRuns, String type) throws IOException {
        StopWatch   sw  = new StopWatch();
        int         cnt = 0;

        sw.start();
        for (int k=0; k<numRuns; ++k) {
            List<String> lines = runUncompress(c, file);
            assertThat(lines, notNullValue());
            cnt++;
        }
        sw.stop();

        assertThat(cnt, is(numRuns));
        System.out.printf("Time of %s decompressor running '%s' job = %s (%.3f ms/file)%n", c.name(), type, sw, sw.getTime() / (double)numRuns);

        return sw.getTime();
    }

    private List<String> runUncompress(UncompressStreamCreator c, String file) throws IOException {
        InputStream                 is = this.getClass().getResourceAsStream(file);
        assertThat(is, notNullValue());

        List<String> lines;
        try {
            lines = IOUtils.readLines( c.wrap(is) );
        } finally {
            c.dispose();
        }

        return lines;
    }

    static interface UncompressStreamCreator {
        InputStream     wrap(InputStream is) throws IOException;
        void            dispose();
        String          name();
    }

    static class HadoopUncompressStreamCreator implements UncompressStreamCreator {
        private CompressionCodec        codec;
        private Decompressor            decompressor;
        private CompressionInputStream  in;

        public HadoopUncompressStreamCreator() {
            CompressionCodecFactory     f = new CompressionCodecFactory(new Configuration());
            codec = f.getCodec(new Path("foo.gz"));
        }

        public InputStream wrap(InputStream is) throws IOException {
            decompressor = CodecPool.getDecompressor(codec);
            in           = codec.createInputStream(is, decompressor);
            return in;
        }

        public void dispose() {
            IOUtils.closeQuietly(in);
            CodecPool.returnDecompressor(decompressor);
        }

        public String name() {
            return "Hadoop ";
        }
    }

    static class VanillaUncompressStreamCreator implements UncompressStreamCreator {
        private InputStream in;

        public InputStream wrap(InputStream is) throws IOException {
            in = new GZIPInputStream(is);
            return in;
        }

        public void dispose() {
            IOUtils.closeQuietly(in);
        }

        public String name() {
            return "Vanilla";
        }
    }
}

Libraries used (excl Hadoop):

• Commons Lang and IO
• Mockito

Almost ten years later it is time to start the company engine again and steer Ribomation out at the ocean. As always I will focus on emerging and disruptive technologies. Cloud Computing (CC) is definitely of that kind. CC will change the way we design and develop applications.

There are three use cases for CC:

1. Extra server(s)
2. Elastic (scalable) applications
3. Massive data computation

If you need some extra capacity, for example testing server, number 1 above apply. If you need to design applications that can scale to 100.000s of users, number 2 apply. And, if you need to process large amount of data, number 3 applies.

I wasn’t aware of the multitude of actors implementations in Java, as the second article describe. The author Alex Miller implemented the same problem (Rock-Paper-Scissors) for each actor realization and compared the code and effort. This was interesting reading indeed.

Thread Method Invocation (TMI)

Many years ago, back in 2002 to be exact, I implemented a library for thread method invocation (TMI) in Java. The idea was to provide various message passing techniques to Java, ranging from simple mailboxing to non-deterministic rendezvous. The library is essentially different implementation of message queues.

Together with the library I wrote a (long) tutorial that started from the very beginning with motivation of why synchronized and wait/notify/notifyAll are needed and then step-by-step moved up in the abstraction level via different forms of message passing, ending in non-determinsitic rendezvous, inspired by the Ada programming language. The article was submitted to JavaWorld, but was declined. After that I was busy with so many other things that the idea and the libray went into limbo. Perhaps it might resurrect nowadays.

After having read the second article with its various Rock-Paper-Scissors implementations, I couldn’t resist the temptation to do my own implementation of Rock-Paper-Scissors using TMI. The rest of this post describes my implementation.

Before I continue, let’s state first that TMI is not an actors model. It is close in spirit, becuase it’s a message passing model, but do not honor the value passing semantics. You can pass what ever object you want as a sender argument or as a response object (rendezvous). Still I consider TMI be a very useful concurrency model and simplifies designing thread based Java programs a lot.

Rock-Paper-Scissors using TMI

The main class is simple and straight forward, let’s show it first. It creates two players and a coordinator and kicks the latter to start the game. The program runs for a specified number of seconds.

public class RockPaperScissorsUsingTMI {
    public static final String ROCK     = "rock";
    public static final String PAPER    = "paper";
    public static final String SCISSORS = "scissors";

    public static void main(String[] args) throws InterruptedException {
        int     runIntervalInSeconds = 20;
        if (args.length > 0) runIntervalInSeconds = Integer.parseInt( args[0] );

        Player          p1 = new Player(1);
        Player          p2 = new Player(2);
        Coordinator     c  = new Coordinator(p1, p2);

        c.start(); p1.start(); p2.start();
        c.startPlay();

        Thread.sleep(runIntervalInSeconds * 1000);
    }
}

Here is a sample output of running the program.

>java -jar RockPaperScissorsUsingTMI-1.0.jar 15
   0) Player-1: scissors -> paper
   1) Player-1: scissors -> paper
   2) Player-1: scissors -> paper
   3) Player-1: rock -> scissors
   4) Player-2: scissors -> paper
   5) Player-2: rock -> scissors
   6)      TIE: scissors
   7)      TIE: scissors
   8 ) Player-2: rock -> scissors
   9) Player-2: scissors -> paper
  10) Player-2: rock -> scissors
  11) Player-1: rock -> scissors
  12) Player-2: rock -> scissors
  13) Player-1: scissors -> paper
  14) Player-2: rock -> scissors
  15)      TIE: paper
  16) Player-1: rock -> scissors
  17) Player-2: paper -> rock
  18)      TIE: rock
>

The Player

The player class below is simple, but illustrates the TMI realization. In this case I have chosen to be close to the actors model and are using an unbounded message queue. The interesting methods are play() and receive() which shows the ’sender’ side and the ‘receiver’ side of a message queue. The sender invokes play(), which inserts a message into the queue. Because the queue is unbouded, this is not a blocking call. It’s easy to change the queue to a rendezvous queue, which results in the sender are blocked until the receiver puts a reply. Inside the run() method, a player recieves the coordinator. The player is blocked as long as the input queue is empty. Then it waits for a random amout of time and performs a move. It responds back to the coordinator using itself as argument.

public class Player extends Thread {
    private static final List<String>   moves = Arrays.asList(ROCK, PAPER, SCISSORS);
    private static final Random         r = new Random();
    private MessageQueue                playMsgs = new UnboundedMessageQueue();
    private String                      move;

    public Player(int id) {
        super("Player-"+id);
        setDaemon(true);
    }

    public void run() {
        try {
            while (true) {
                Coordinator c = receive();
                delay( r.nextInt(1000) );
                move = makeMove();
                c.throwResult(this);
            }
        } catch (InterruptedException e) {System.out.println(getName()+" Interrupted");}
    }

    public void     play(Coordinator master) {
        try {
            playMsgs.put(master);
        } catch (InterruptedException e) { }
    }
    private Coordinator     receive() {
        try {
            return (Coordinator) playMsgs.get();
        } catch (InterruptedException e) {return null;}
    }

    private String    makeMove() {
        return moves.get( r.nextInt(moves.size()) );
    }
    public String getMove() {
        return move;
    }
    protected Player setMove(String move) {
        this.move = move;
        return this;
    }

    private void delay(int numMilliSecs) {
        try {
            sleep(10 + numMilliSecs);
        } catch (InterruptedException e) { }
    }
}

The Coordinator

The coordinator is slightly more complex, due to its responsibilities. It waits for a start message, then ask each player to play and receives the throw messages in either order. It then evalutes who won this round. The concurrency part is not very complicated. It has two unbouded queues, one for each message type. And for each message type it has a public sender method (startPlay/throwResult) and a private receive method (receiveStart/receiveThrow). The Permutation class is just a helper for computing or winner.

public class Coordinator extends Thread {
    private MessageQueue    startMsgs = new UnboundedMessageQueue(),
                            throwMsgs = new UnboundedMessageQueue();
    private Player          player1, player2;

    public Coordinator(Player player1, Player player2) {
        super("Coordinator");
        this.player1 = player1;
        this.player2 = player2;
        setDaemon(true);
    }

    public void run() {
        try {
            for (int count = 0; true; count++) {
                receiveStart();

                player1.play(this);
                player2.play(this);

                Player  first  = recieveThrow(),
                        second = recieveThrow();

                if (isTie(first, second)) {
                    System.out.printf("%4d) %8s: %s%n", count, "TIE", first.getMove());
                } else if (isWinning(first, second)) {
                    System.out.printf("%4d) %8s: %s -> %s%n",
                            count, first.getName(), first.getMove(), second.getMove());
                } else {
                    System.out.printf("%4d) %8s: %s -> %s%n",
                            count, second.getName(), second.getMove(), first.getMove());
                }

                this.startPlay();
            }
        } catch (InterruptedException e) {System.out.println(getName()+" Interrupted");}
    }

    public void     startPlay() throws InterruptedException {
        startMsgs.put(this);
    }
    private void    receiveStart() throws InterruptedException {
        startMsgs.get();
    }

    public void     throwResult(Player p) throws InterruptedException {
        throwMsgs.put(p);
    }
    private Player  recieveThrow() throws InterruptedException {
        return (Player) throwMsgs.get();
    }

    protected boolean isWinning(Player first, Player second) {
        Permutation permutation = new Permutation(first, second);
        return  permutation.dominates(ROCK    , SCISSORS) ||
                permutation.dominates(PAPER   , ROCK)     ||
                permutation.dominates(SCISSORS, PAPER);
    }

    protected boolean isTie(Player first, Player second) {
        return new Permutation(first, second).tie();
    }

    private static class Permutation {
        private Player  first, second;

        private Permutation(Player first, Player second) {
            this.first = first;
            this.second = second;
        }
        public boolean dominates(String m1, String m2) {
            return first.getMove().equals(m1) && second.getMove().equals(m2);
        }
        public boolean tie() {
            return first.getMove().equals( second.getMove() );
        }
    }
}

Source code

My application is developed using Maven, which means it very easy to download and unpack the sources and then type

mvn package
java -jar target\RockPaperScissorsUsingTMI-1.0.jar 60

Links

• Source code
• Compiled JAR file
• Thread MessageQueue library
• Towards Ada Style Thread Communication in Java
• Understanding actor concurrency, Part 1: Actors in Erlang
• Understanding actor concurrency, Part 2: Actors on the JVM
• Cuckoo for Concurrency

JavaFX

The key note talk at the beginning described JavaFX, SUNs new “SilverLight and Flash” killer. The demo showing how to flip through a book with very realistic behaviour, was impressive. On the other hand I’m not convinced SUN is gonna make it. MS is pushing out SilverLight in each Windows Update and SUN simply have not that capability to “pre-load” desktop browsers with the appropriate plugin. Remember the applet war ten years ago. Don’t get me wrong - I like JavaFX, however I’m pessimistic. Anybody still remembering JINI?

Capuchin

The second talk I attended was Ericsson’s new JavaME+Flash/light environment. I’m even more pessimistic about this new tool. It might be a bright piece of technology - I cannot really judge without getting my hands on it. However, will it ever be supported by other vendors? Will it be open source? How many of Ericssons own phone models will have it? There are way too many questions, before one starts to invest time and money on a new (isolated) platform.

Groovy

After lunch it started to be fun. First there was a talk about Groovy support in JetBrains’ IntellijIDEA. I have been using IDEA since the beginning of 2002 and usually uses the latest version all the time. For me personally there wasn’t anything new, becuase I have done some Groovy and Grails hacks using IDEA already. But the presentation was fun and entertaining and hopefully it inspired some in the audience to embark the Groovy way.

JPA 2.0

I realized that EJB3 / JPA still is not my cup of tea. Either I prefer something more high-level, like Grails or something more low-level, like Spring’s JDBC-Template.

Puke

A fun role playing of the importance of thinking and not following, when it comes to productive software development. A standpoint I fully support.

JRockit

Some interesting optimization techniques for the JRockit JVM. However, why did they start to compete with SUN in the first place?

Java++

Ola Bini is always fun to see on stage. He outlined the future of Java as a system implementation language and new dynamic languages on top of the JVM, such as Groovy, Scala, JRuby and others. I fully agree. Java has over the years become a dinosaur and it’s time to move on. Sort of, the same evolution as for 15-20 years ago when C faded away for C++.

Scala

My best experience of the day was Jonas Bonér talking about Scala. I have been curious about Scala a while now, but haven’t really reached above the threshold of actually reading and playing around with it. This has now changed. I’m a Groovy advocate, but will over this year make room for Scala as well. I doubt Scala is ready for prime time yet - not because any technical limitations, rather because of commercial aspects. But the day will come and I will be ready that day.

Scala seems to be a multi-paradigm language; static typing but allowing dynamic type constructs, object oriented programming, functional language programming and actors based concurrent programming. I really like the latter. As far as I understand, the support for message passing is inspired by the Erlang programming language. Back in the beginning of the 90’s, as did some hacks in Erlang, like a simulator for a small phone exchange with support for connecting it to a real PBX exchange (MD110). This was part of my teaching course in real-time systems programming, for Royal Inst of Technology in Stockholm. Besides of Erlang, I used Concurrent C++ as well in the course. Those were the days.

I have never liked the path taken by the current support of concurrency in Java. Doug Lea’s library, which now is the java.util.concurrent package, is simply the wrong way to go. Not because the library is bad - it is not. But, the users are . . . I mean, it is inherently difficult to design concurrent programs right. As soon it starts to be a little more complex, than a bunch of threads doing some asynchronous work. Message passing is the right way to realize concurrent programs. It is a pity, my implementation of thread method invocation from 2002 never got any attention. Well, that’s life. If you are interested, you can find the article here.

Summary

The first presentation about WebSockets and the last presentation about Scala, was my personal highlights of the 2009 JFokus conference.

The first session regarding the part of the upcoming HTML 5 specification, called WebSockets and Server Side Events, was really, really interesting. Everybody, that have tried various ways of pushing data from the server to the web clients, know how difficult it is.

For some period of time, people used fat clients (like JavaSwing@WebStart) to connect to the server and then keeping a full-duplex bi-directional socket stream open. However, as more and more internet threats have emerged security guys tend to block all incoming ports except 80 and 443 for applications to use - reasoning like HTTP is decent protocol and well-understood and the web servers (like Apache) are very robust as well. That have put a burden on us developers to invent protocol tranformers, typically performed by some servlet, used to act as gateways between some back-end system and the front-end browser. Everybody, that have tried this knows how intricate it quickly gets. Why, cannot the browser subscribe directly to a JMS topic and react on incoming messages?

This is exact the kind of question, people behind the WebSockets upcoming standard have been asking and decided to provide an answer for.

A web socket creates a bi-directional HTTP tunnel and within, it can transport application level protocols such as XMPP, STOMP, IMAP/SMTP and many more. From an internet technology point of view, this is the best thing happened since the the invention of sliced-bread.

The second session, after lunch, on the other hand was a little bit disappointing. It was presented by Kirk Pepperdine of JavaPerformanceTuning. However, he had many problems with the both the presentation device (not his fault) and the demoes (his fault). My impression was that he wasn’t really well-prepared. Having a background myself, in both training (10+ years) and performance tuning (2+ years), I must say this was below par. Never ever run a live demo without tripple-checking everything and keep some screen-shots up the sleeves, if running into disasters (shit happens indeed).

The first session was presented by Jonas Jacobi of Kaazing, which seems to have been heavily involved in the realization of the new standard. The point is, there are no browsers yet supporting HTML 5 or WebSockets. Kaazing provides an open-source emulation layer that fully implements the standard that can be used in the meantime. I’m really looking forward to get some time playing around with this new exiting technology.

Virtualization + DataCenter + PublicAccess = CloudComputing

Although there are more than one provider and others to follow, Amazon (AWS) has pioneered the field and I will refer to AWS only when describing hands-on procedures.

Sign Up

The first thing to do is to create an AWS account and register a credit card - yes it’s not free, although not expensive either. The pricing starts at USD 0.10 per hour for the smallest machine type, plus some extra for storage and bandwidth. For a single lightly loaded server it adds up to USD 2.5-3 per day.

You should also sign up for EC2 and S3, which is just a single click on a button.

Get the Keys

The second thing to do, is saving the ACCESS and SECRECT keys of your account to a text file, because you will need these character sequences from time to time.

The following task is to generate a cryptographic key pair. Most convenient is letting AWS do it for you, but you can also upload you own public certificate. AWS only stores the certificate part. That means, after AWS has generated your key pair, there is a download button on the result page. Use that button to download your private key, because it is your only chance to get a working key pair. Ensure you download and store both the key and the certificate.

Get the Tools

Now when you have signed up you need the tools to start interacting with AWS and EC2. The fourth task to do is to download and install the AWS EC2 API Tools plus a very handy plugin to Firefox.

AWS/EC2 API Tools

This set of command line tools are implemented in Java, so in case you don’t have a decent JDK/JRE already installed, now is the time to fix that.

You need to set four environment variables in order for the tools to work. These are

• EC2_HOME
• EC2_CERT
• EC2_PRIVATE_KEY
• PATH

The last (PATH) should point to the bin directory of EC2_HOME. The cert and key variables should point to the PEM files you downloaded during the key pair task above. Now test the command line tools

ec2-describe-images --help
ec2-describe-images --verbose
ec2-describe-images --owner amazon

The first line shows the built-in help and the second how to see what SOAP data are interchanged. Every command responds to these options. The third line shows how to filter out the machine images provided by Amazon. In addition to Amazon, there are plenty of third-party images available. My personal preference is to use Ubuntu images created by Eric Hammond.

ElasticFox

Besides of using the AWS EC2 API command line tools, there are many others available implemented in Perl, Ruby, C# and more. However, my clear favorite is not a command line tool, rather a GUI. Elastic Fox is a plug-in to FireFox and provides you with a very convenient access to EC2. This plug-in is so valuable that I am using it all the time, instead of the command line tools

Prepare before launch

Before you can launch your first AMI (Amazon Machine Image), you need fixing three additional things.

1. Generate an EC2 logon key pair
2. A SSH client for Linux/Unix AMIs. For a Windows AMI, will use the built-in Remote Desktop client to logon via RDP.
3. Create a security group (AWS-EC2 firewall rule) enabling access to SSH (port 22) or RDP (port 3389).

The EC2 logon key pair is different from the key pair you created in step three. The logon keys are used for SSH access and to encrypt/decrypt the Windows Administrator password. In contrast to the first key pair, you can create as many logon key pairs you like and use them for different purposes. Every key pair (or cert) is referred to by its name. Ensure you save the private key part to a PEM file on your own computer, because you will need that key for the SSH logon.

You need a remote access client, which for a Linux (Unix) machine will be SSH. If you are running Linux at your desktop, you probably already have ssh installed. If you are running Windows at your desktop, you need a SSH client like PuTTY or install an environment like CygWin. If you are going for PuTTY, install the full distribution or more exact PuTTY and PuTTYgen. You need the latter to convert your EC2 logon private key from PEM to PuTTY’s own format PPK (PuTTY Private Key).

By default, there are no ports opened into your running machine instances, which means you cannot logon unless you open an appropriate port. You do that by creating a security group (firewall rule). Use ElasticFox to create a new firewall rule (web), which permits access to port 22 (SSH) and 80 (HTTP) for all IP numbers (0.0.0.0/0). The funny zeroes denotes an IP number group (CIDR). You can study that topic at WikiPedia.

Launch a virtual server

Now is the time to lauch the first virtual server. Choose, for example, the Ubuntu 8.10 server 32bit, provided by Eric Hammond.

Right click and choose “Launch…”

Check that you are using your logon key, your firewall rule that at least open port 22 and the type is the smallest in only one instance. You will now see that the machine instance is booting (pending).

Click the refresh button, until you see the instance is running. When that happens, you will see that the instance now has a public IP and DNS name.

Logon to the instance

Use SSH to logon to the instance. If you are using PuTTY, you need to convert the PEM formatted private key into PuTTYs own key format PPK. Use PuTTYgen for that task. Load the PEM key and save as a private key. Ensure you give it the same base file name (differing only in the file extension), so ElasticFox can create file path to the key. Review the tools settings .

You can use ElasticFox to launch your SSH client directly. Just right click on the instance and choose “Connect …”. If PuTTY complains of not finding your key, double-check key template settings in the Tools setting of ElasticFox. If everything goes well you should be logged on to your own server in the cloud.

When your are done. Don’t forget to shutdown your instance again. Remember, AWS is affordable but not gratis.

EC2 provides you with one or more virtual computers. You can choose from many pre-built images or roll your own installation - either from scratch or by modifying an existing image. Most of the images runs Linux (Fedora and Ubuntu), some OpenSolaris and recently there are Windows images as well. In AWS terminology you launch an AMI (Amazon Machine Image) giving you a machine instance.

The storage model in the AWS cloud is different from common sense, i.e., concrete computers. In the cloud, there are several storage types.

• Fixed
• Ephemeral
• Persistent
• Permanent

Fixed storage is the AMI. Every time you launch an instance based on a specific AMI-ID, you get back the same storage content, which is the operating system plus the installed applications.

During the life time of a machine instance it has access to a file system. However, as soon as the instance terminates all data is lost and the ephemeral storage reclaimed. This indeed, is very different from physical hardware, where a server crash (most of the time) means you can reboot and re-read the data at the harddrive.

Clearly, one need to put business data somewhere else. Until recently, the only choice was S3 which was one of the first services of AWS. S3 is a howngrown distributed storage system, which can store unmodifiable blobs. Although, S3 serves it purpose it does not lend itself for finegrained read/write accesses. A while ago, AWS introduced EBS, which is a virtual harddrive. You allocate a drive of size between 1-1000 GB and attache it to a running machine instance. Within the instance the drive pops up as a new disk. The same procedure applies as for a physical disk, you have to format it (e.g. Ext3 or NTFS) and mount it. If the machine instance terminates the data on the virtual disk remains and can quickly be attached to another machine instance, which this time sees an initialized non-empty disk.

There is a non-zero probability that the virtual disk might fail/terminate, therefor a backup strategy is still needed. It’s very easy to take a snapshot of an EBS and automatically store the image in S3. Later on, it’s possible to (re-)create another EBS based on a saved snapshot in S3. In other words, this is a convenient recovery.

When a machine instance boots, it receives a dynamic IP number and a DNS name (for example: ec2-75-101-207-168.compute-1.amazonaws.com). It’s an understatement to point out that dynamic IP and host name complicates accessibility in the cloud. The solutions available have been to rely on a non-cloud based front-end listening on a public static IP address with a well-defined DNS name or Dynamic DNS services, such as DynDNS.

Recently, AWS introduced allocatable IP addresses (EIA). You allocate an EIA and assigns it to a running machine instance. If the instance goes down, it’s very easy to lauch a new instance and (re-)allocate the IP to the new recovered server. With a static IP address, it’s possible to let a DNS service refer to the cloud service using an understandable hostname.

During this year I have been “kicking the tires” of the next logical step of virtualization; from personal/organizational virtualization into global cloud computing. The prime player of this new technology area is Amazon - the online book company. Other players, such as Google and Microsoft, are expected to follow.

The concept is simple: use an (open source) virtualization technique (Xen, @WikiPedia), apply it to a global collection of data centres, define a simple pricing model and tell it to the developer community. The result on the other hand is far from simple - indeed it is a revolution. Why? Because it changes our perception of how to design a system architecture.

When I started with computers, which - by the way wasn’t that long after the Jurassic period - both processing power and memory space were scarce resources. Over time these restrictions of the mind has gradually dissolved, leading to the war-cry ‘memory is cheap, so let’s waste it‘. Today, nobody would be embarrassed of a 4GB foot print application. However, we still design a system architecture in terms of a few heavy weight nodes, say 2 or 4 nodes in a cluster of WAS/WLS/JBOSS app servers plus at least one DB server.

This has two consequences; either we buy too much hardware wasting money or we buy too little hardware leading to unacceptable response times and crashes. The right amount of hardware is not possible to achieve, because the system load varies over time.

With virtualization in general and a global cloud computing supplier as Amazon in particular we have relaxed the last bit of the system design restraints, leading to the contemporary war-cry ‘servers are cheap, so let’s waste it‘.

With cloud computing we have instant access to an unbounded number of computing resources, whenever we need it. (I hope you don’t take me literary when I’m using the term ‘unbounded’. I simply mean many more than you uses today).

From the system design point of view the interesting topic is: which factors of my architecture will change when I run my application over a dynamic number of servers, all with ephemeral storage?

I intend to describe Amazon Web Services (AWS) and its cloud computing service EC2 (Elastic Compute Cloud) from a practical point of view, in a series of blog posts. This was the first, introductory post.