During my evaluation of highly scalable technologies I incurred in some performance problems with the EJB3 implementation. It seems to me that it is a quite common problem

Yesterday I was getting very dissappointing results from the benchmarks of the EJB3 implementation of the sample application. I have discovered some nice hints for optimizing Hybernate and EJB3 applications and a very good video on EJB3. This hepled me understand why my EJBs were not updated properly, but most of all why I was getting such poor performance.

The performance problem was due to the use of eager fetching on a many to many relationship. The relationship in question was friendship between users. This is a many to many relationship with itself. This means eager fetching is propagated transitively, so each time I loaded a user, all the friends were loaded as well, and also the friends of the friends and the friends of… basically the whole table.

By default many to many relationships use lazy fetching, but I changed this to eager when I wrote the application. The reason I had eager fetching on this relationship is that when I tried to get the number of friends a user had, my appserver was complaining that it couldn’t be done with lazy fetching. My error was in performing this through user.getFriends().size(). What I’m doing now instead is asking the database to give me the number of friends by using a query like “SELECT count(f) FROM user u JOIN u.friends f WHERE…”.

After that I changed some transaction attributes so that read only operations do not require transactions. Given the semantic of the methods I don’t require a strong level on consistency, so it’s relatively safe to do this. This minimizes delays due to contention and increases the paralellizability (try pronouncing this aloud) of the applications.

The result was that now my application runs 10 times faster. Now I’m getting 79 requests per second if I run the server on an EC2 instance and the client on my machine. This is just a little slower than the 100 requests per second obtained by the pojo in memoty solution, which means that EJB3 is pretty fast. I still have to test this without the communication bottleneck to be sure of the actual performance.

Here’s a cool but unfortunately useless example of java generics, combined with reflection, combined with dynamic proxies.

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.ArrayList;
import java.util.List;

import sun.reflect.generics.reflectiveObjects.NotImplementedException;
import sun.reflect.generics.tree.ReturnType;

public class Foreach {
  @SuppressWarnings("unchecked")
  public static <T> T foreach(T... elements) {
    ApplyOnArrray<T> handler = new ApplyOnArrray<T>(elements);
    return (T) Proxy.newProxyInstance(elements[0].getClass().getClassLoader(),
      new Class[] { elements[0].getClass().getInterfaces()[0] },
      handler);
  }

  public static <ReturnType> List<ReturnType> get(ReturnType returnValue) {
    Collector collector = (Collector) Proxy.getInvocationHandler(returnValue);
    return collector.getReturnValues();
  }

  public static void main(String[] args) {
    IFoo f1 = new Foo();
    IFoo f2 = new Foo();
    IFoo f3 = new Foo();
    IFoo f4 = new Foo();

    List<IString> list = get(foreach(f1, f2, f3, f4).sayFoo());
    System.out.println(list);
  }
}

class Collector implements InvocationHandler {
  private final List returnValues;

  public Collector(List returnValues) {
    this.returnValues = returnValues;
  }

  public List getReturnValues() {
    return returnValues;
  }

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    // TODO get(foreach(elements).method(args))
    throw new NotImplementedException();
  }
}

interface IString { String toString(); }

  class StringImpl implements IString {
    private String s;
    public StringImpl(String s) { this.s = s; }
    public String toString() { return s; }
  }

interface IFoo { IString sayFoo(); };

class Foo implements IFoo {
  public IString sayFoo() {
    System.out.println("foo");
    return new StringImpl("foo");
  }
};

class ApplyOnArrray<T> implements InvocationHandler {
  private final T[] elements;

  public ApplyOnArrray(T... elements) { this.elements = elements; }

  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    Method targetMethod = elements[0].getClass().getMethod(method.getName(), method.getParameterTypes());

    List returnValues = new ArrayList();
    for (T element : elements) returnValues.add(targetMethod.invoke(element, args));

    // return a proxy for the result
    return (T) Proxy.newProxyInstance(elements[0].getClass().getClassLoader(),
    new Class[] { targetMethod.getReturnType() },
    new Collector(returnValues));
  }

}

I had this idea in a dream (too much work) and fortunately I could still remember it in the morning. Who knows, I might have dreamt also a solution that works with classes.


I wrote this code a couple of weeks ago. It’s a nice idea on how to use generics in order to reduce the pain of using the Eclipse API.

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import org.eclipse.jface.action.IAction;

import org.eclipse.jface.viewers.ISelection;
import org.eclipse.jface.viewers.StructuredSelection;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.ui.IObjectActionDelegate;
import org.eclipse.ui.IWorkbenchPart;

/**
 * An eclipse action delegate that performs operations on objects of the
 * specified type. Automatically handles multiple selections. Extend this class
 * specifying the type parameter of the object that the action operates on.
 * Implement the main logic in {@link #runOn(Object, IAction)}.
 *
 * @author Jaksa Vuckovic (vuckovja)
 *
 * @param
 */
public abstract class TypedAction implements IObjectActionDelegate {

  protected List selectedElements = new ArrayList();
  protected Shell shell;

  public void setActivePart(IAction action, IWorkbenchPart targetPart) {
    this.shell = targetPart.getSite().getShell();
  }

  /**
   * The default implementation will iterate over all the selected elements and
   * invoke {@link #runOn(Object, IAction)} on every on of them.
   *
   * @see org.eclipse.ui.IActionDelegate#run(org.eclipse.jface.action.IAction)
   */
  public void run(IAction action) {
    for (T element : selectedElements) {
      runOn(element, action);
    }
  }

  /**
   * Implement this to invoke the operation on one of the selected elements.
   * This method is called by {@link #run(IAction)} on every selected element.
   *
   * @param selectedElement one of the selected elements
   * @param action the action that has been run
   */
  protected abstract void runOn(T selectedElement, IAction action);

  /**
   * The default implementation will enable the action if all the selected
   * elements are of type T.
   *
   * @see org.eclipse.ui.IActionDelegate#selectionChanged(org.eclipse.jface.action.IAction,
   *      org.eclipse.jface.viewers.ISelection)
   */
  public void selectionChanged(IAction action, ISelection selection) {
    selectedElements.clear();

    boolean enabled = false;

    if (selection instanceof StructuredSelection) {
      enabled = true;

      for (Iterator it = ((StructuredSelection) selection).iterator(); it.hasNext();) {
        try {
          T selectedElement = (T) it.next();
          selectedElements.add(selectedElement);
        } catch (ClassCastException e) {
          enabled = false;
          break;
        }
      }
    }
    action.setEnabled(enabled);
  }
}

Try to refactor your actions to extend this class and you will find a significant reduction in code size

PS: syntax highlighted by Code2HTML, v. 0.9.1

The equivalent of the hello world for parallel languages is the quicksort algorithm. The quicksort algorithm is based on the divide et impera principle, which makes it a good candidate for parallelization. In this article we will go past arrays and apply parallelism to more complex data structures such as graphs.

We will start by performing a DFS (Depth First Search). Given a starting node, visit all other reachable nodes. This algorithm can be adapted to solve many problems. Let’s see the basic form of this algorithm:

public void dfs(Node n) {
  Set<Node> visitedNodes = new HashSet<Node>();
  dfs(n, visitedNodes);
}

private void dfs(Node n, Set<Node> visitedNodes) {
  if (!visitedNodes.contains(n)) {
    doSomeStuff(n);
    visitedNodes.add(n);
    for(Node neighbor: n.getNeighbors()) {
      dfs(neighbor, visitedNodes);
    }
  }
}

The straightforward translation using the fork/join framework would look like:

public class DFS extends RecursiveAction {
  public DFS(Node n) { this(n, new HashSet<Node>()); }

  private DFS(Node n, Set<Node> visitedNodes) {
    this.n = n;
    this.visitedNodes = visitedNodes;
  }

  public void compute() {
    if (!visitedNodes.contains(n)) {
      doSomeStuff(n);
      visitedNodes.add(n);
      DFS[] subtasks = new DFS[n.getNeighbors().size()];
      for(int i = 0; i < n.getNeighbors().size(); i++) {
        subtasks[i] = new DFS(n.getNeighbors().get(i), visitedNodes);
      }
      forkJoin(subtasks);
    }
  }
}

You may have noticed that this code is actually not thread safe. If we have a subgraph with a diamond topology, we may end up visiting a node more than once. In the failing scenario one thread will check whether node has been visited, and while it’s visiting the node, another thread would arrive to the same node via a different route, seeing that the node hasn’t been visited and start visiting it.

In order to fix that we must add a bit of synchronization. First of all we will mark a node as being visited even before visiting it, then we will define a critical section around the check and mark operations:

  public void compute() {
    boolean shouldVisit;
    synchronized(visitedNodes) {
      shouldVisit = !visitedNodes.contains(n);
      visitedNodes.add(n);
    }
    if (shouldVisit) {
      doSomeStuff(n);
      DFS[] subtasks = new DFS[n.getNeighbors().size()];
      for(int i = 0; i < n.getNeighbors().size(); i++) {
        subtasks[i] = new DFS(n.getNeighbors().get(i), visitedNodes);
      }
      forkJoin(subtasks);
    }
  }

Ok, so now we have a working algorithm, but there still is a problem. Can you spot it? Try to figure out a solution.
I will post the solution in my next post and talk a little bit about a parallel BFS (Breadth First Search).

Recently I came across a class used to store some application configuration. The configuration was stored in an XML file which was parsed in the constructor of the class. Each method of the class started with getting the root element of the XML file and if that element did not exist it needed to be created. That was a lot of code repetition that could be extracted into a common private method. But before I started changing the code, I realized it could be done in a more elegant way.

Instead of performing the check at every method invocation, I would do it only in the constructor and ensure that no method breaks that condition. This is called a class invariant.

An invariant is a condition which is always true in any state of the object (or system). Invariants are used heavily when designing algorithms, but a lot of programmers somehow forget about them.

In my case it is pretty simple, the invariant says: “the document has the root element”. The document is loaded when the class is created and if there is no root element, one is created. No method of the class will reload the document, nor delete the root element.

Requirements for Using Invariants

Having good ecapsulation is necessary when using invariants, because you don’t want to have a method outside of your class that can break the invariant.

Invariants need to be documented, anyone who modifies your class should be aware of the invariants. So put a section of comments at the top of your class stating all the invariants.

Invariants need to be tested: put assertions at the end of each test.

Pitfalls

As with everything there are downsides on using invariants.

When using invariants in combination with inheritance, things may get complicated. If you extend a class that preserves some invariants, first of all, you need to be aware of the invariants, and then ensure that you don’t break them. For example if you have a template method in the parent class, and you implement one of the abstract methods used by the template method, you would need to run the tests of the parent class on your subclass. You can make an invariant unbreakable by the sublcasses by declaring the relative data structures as private (as opposed to protected).

Your invariant might be too strong. On a previous project, I needed to create a file system structure (assuming it won’t be modified externally) with a lot of files that had naming conventions. There were also a lot of conditions like file A must exist, if file C exists then we need file B etc. These conditions were required in order to run a sequence of legacy tools on the files. We performed all the validation at the beginning so we were sure that you could run all the tools.

But running all the tools wasn’t always required. So instead of maintaining all the conditions as invariants, we refactored to use a minimal set of conditions as invariant, and express all the others as preconditions to running the relative tools, and verifying preconditions at the beginning of the method.

If you realize that you are maintaining too many invariants, it might be the case that you need to decompose your class into several classes. You might even end up inventing some reusable primitives (monitors, transactions, atomic bcast)

A few days ago, Brian Goetz came to visit a colleague of mine in our offices and I had the opportunity to hear some of the new concurrency features coming in JDK 7. We talked about the fork/join framework and Brian kindly showed us the presentation he gave at JavaOne.

The new fork/join model is a Java implementation of a parallel loop. It allows you to perform concurrent processing on relatively large amounts of data by distributing the load among different threads. So if your hardware platform has a lot of CPUs/cores you will be able to see significant performance improvement.

This is how it works: you create a number of tasks and you split the workload among them. Then you run all of your tasks concurrently using the coInvoke() method. Tasks are allocated to a pool of workers for processing. After all of your tasks have executed the coInvoke() method will terminate. This allows you to run many independant operations on a number of data.

Moreover the framework supports recursion, which means, that tasks can create and execute other tasks. This is very important because it allows you to parallelize practically any divide-et-impera algorithm. The example Brian has shown was Mergesort, but you are not limited to array data structures, you could for example do a BFS on a graph, or solve the maximum flow problem.

On top of the fork/join model a very useful parallel array data structure has been implemented that allows you to perform map, filter, sort and reduce operations. This is where things get interesting, because you start to express your application logic in terms of array operations.

The framework is nicely designed, smartly implemented and will be very useful with the forthcoming growth of the number of processor cores. But is this really the best framework available? There are several libraries for Java that already implement the worker farm model and moreover there are many languages that have native support for such things (HPJava, Fortran, Occam). Some libraries even go one level further and distribute the load on a cluster of machines (Map/Reduce, Hadoop).

What struck me most of all was that they didn’t integrate this parallelism in the language and the JVM. This was their most significant advantage over the existing solutions and they didn’t make use of it. It would have resulted in a much cleaner syntax and important optimizations could have been done at the JVM level. Maybe this will be a good testbed to something more radical in JDK8… or perhaps Scala?

PS: I apologize about some missing references, I’ll try to add these asap.

With this I don’t want to say distributed SCMs are not the way to go. On the countrary. They just need to put in place mechanisms to prevent branch proliferation, but still take advantage of a decentralized architecture and fault tollerance.

Yeah, you read correctly: “Playing with Jazz”. Jazz is the new Application Lifecycle Management software developed by IBM Rational. In other words it is an all-in-one Source Control Management, Continuous Integration and Issue Tracking server. Currently I’m developing a lot of plugins for my client that are meant to integrate Jira, Subversion, Maven, ClearCase, our custom bug tracking software, our custom made overnight testing and reporting, Eclipse IDE etc. Jazz is supposed to provide these features and much more out-of-the-box. I’ve seen the demos and I was really impressed. So, now that it’s open for download, I registered and downloaded the server and the client.

Well, things are not that impressive when you start working with it. The product isn’t that ergonomic. It presents a relatively steep learing curve for the basic functionality.

Ideally an administrator would:

1. install the server (it should be added automatically as a windows/*nix service)
2. start the Jazz service
3. connect to the web-admin interface
4. create some users

The developer:

1. installs the Eclipse Jazz plugin
2. connects with his username/password
3. uploads a project or two in the repository

The server:

1. autodetects how to build and test the projects (eclipse/ant/maven)
2. starts doing this immediately with a predefined schedule (continuously)
3. if there are failures it notifies the responsible developer
4. build and test status are visible in the status bar of the IDE

What happens in reality is not that simple. You need to create a project area, define the process, create a team area (A team area is just a team, the word “Area” was added so that you don’t confuse the representation of a team in Jazz with the people sitting around you), create a development line, create a workspace, create a stream from your workspace to the development line, create an iteration plan, an iteration, a build configuration, a build engine etc.

What I would like to see is a product where the novice user and even the administrator initially, don’t need to know about project areas, iteration plans, development lines, streams. All these are advanced features. The first impact should present a shared versioned storage where you place your projects and it tells you whether the projects are building and whether the tests are passing. Users should be able to add tasks without having to define an iteration or an iteration plan. And most of all, I don’t like the Team Artifacts view. It’s an heterogeneus collection of entities in the Jazz server unimmaninatively organized into a tree. Integration with Eclipse should be tighter. Eclipse already knows how to build and test my projects. Why do I need to specify those things in two different places?

Don’t get me wrong. I don’t want to say that Jazz is overengineered. Most of the entities involved are necessary for such a product. Even multiple project areas and streams. But the point here is that they are presented in the wrong way. Advanced features should be hidden from the user and the product should be usable out-of-the-box. Ok, it took me less than 2 hours to install the server, read the instructions and configure a project, and another hour to troubleshoot the automated build. But there is really no reason why it should take more than 5 minutes.

I really hope that Jazz developers will take this as a constructive critique and deal with these issues before the release of Jazz. Otherwise they risk to loose a multitude of potential customers who need only simple configurations with the most basic process. And it’s from projects like these that you get the most publicity, community involvement and knowledge sharing.

In recent times I was thinking a lot about Dijkstra’s article against the GOTO statement published in Communications of the Association for Computing Machinery (CACM) in 1968. I had the feeling that a lot of people should take one more look at it and was planning to circulate it among some of my friends. This morning I found a copy of the Communications of ACM under my door. It’s the 50th anniversary edition and it opens with the above cited article. Apparently the editor shared my feelings that it is time to look back at the history of programming languages in order to avoid repeating the same mistakes which had caused 20 years of debate. So here it is:

Go To Statement Considered Harmful

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects and I became convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

My first remark is that, although the programmer’s activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to effectuate the desired effect, it is this process that in its dynamic behaviour has to satisfy the desired specifications. Yet, once the program has been made, the “making” of the corresponding process is delegated to the machine.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until that very same point?) If the program text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the descriptions of single actions) it is sufficient to point in the program text to a point between two successive action descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sentence: if we parse them as “successive (action descriptions)” we mean successive in text space, if we parse as “(successive action) descriptions” we mean successive in time.) Let us call such a pointer to a suitable place in the text a “textual index”.

When we include conditional clauses (if B then A), alternative clauses (if S then A1 else A2), choice clauses as introduced by A.R.Hoare (”case[i] of (A1, A2,…..,An)”) or conditional expressions as introduced by J.McCarthy (”B1 → E1, B2 → E2,….., Bn → En”), the fact remains that the progress of the process remains characterized by a single textual index.

As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient: in the case that a textual index points to the interior of a procedure body the dynamic progress is only characterized when we also give to which call of the procedure we refer. With the inclusion of procedures we can characterize the progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic depth of procedure calling.

Let us now consider repetition clauses (like “while B repeat A” or “repeat A until B”). Logically speaking, such clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of realism I don’t wish to exclude them: on the one hand repetition clauses can be implemented quite comfortable with present day finite equipment, on the other hand the reasoning pattern known as “induction” makes us well equipped to retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into a repetition clauses, however, we can associate a so-called “dynamic index”, inexorably counting the ordinal number of the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find that now the progress of the process can always be uniquely characterized by a (mixed) sequence of textual and/or dynamic indices.

The main point is that the values of these indices are outside programmer’s control: they are generated (either by the write up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide independent coordinates in which to describe the progress of the process.

Why do we need such independent coordinates? The reason is –and this seems to be inherent to sequential processes- that we can interpret the value of a variable only with respect to the progress of the process. If we wish to count the number, “n” say, of people in an initially empty room, we can achieve this by increasing “n” by 1 whenever we see someone entering the room; in the in-between moment that we have observed someone entering the room but have not yet performed the subsequent increase of “n”, its value equals the number of people in the room minus one!

The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful: in such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, “n” equals the number of persons in the room minus one!

The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one’s program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs; but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.

It is hard to end this article with a fair acknowledgement: am I to judge by whom my thinking has been influenced? It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey, and that I do not regret their influence upon me. Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark.

The remark about the undesirability of the go to statement is far from new. I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C. A. R. Hoare. In [1, Sec. 3.2.1] Wirth and Hoare together make a remark in the same direction in motivating the case construction: “Like the conditional, it mirrors the dynamic structure of a program more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels in the program.”

In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.

References:

1. Wirth, Niklaus, and Hoare C. A. R.
A contribution to the development of ALGOL.
Comm. ACM 9 (June 1966), 413-432.

2. Böhm, Corrado, and Jacopini Guiseppe.
Flow diagrams, Turing machines and languages with only two formation rules.
Comm. ACM 9 (May 1966), 366-371.

by Edsger W.Dijkstra
Technological University
Eindhoven, The Netherlands