Queue Patterns

Here is a list of all my Queue Patterns:

Rocket Anti-Pattern

Paratrooper Model

Marsupilami Pattern

Indian Train Anti-Pattern

Indiana Jones Pattern

Hamburger Pattern

Water Drop Anti-Pattern

Santa Claus Pattern

Godzilla Anti-Pattern

Opera Lift Pattern

Next time, I can move to my Thread Patterns.

Opera Lift Pattern

In my last part, I presented the Godzilla Anti-Pattern, where you would merge so many messages that a monster size packet would be sent and have negative effects.
 In this part, I would like to present the Opera Lift Pattern. From all the Patterns I presented in this serie, this one is the only one for which I did not come up with the name. I leave all credit for the pattern as well as for the name to our architect while I was working at MyCom, Hugues Bouclier.

The name of this pattern was inspired by the lift in the Opera metro station. If you’ve been there, I must point out that the name was not inspired because the lift is often not working, neither because of the smell. What characterize this lift is that it has a timer. When someone leaps in, the timer starts counting 30 seconds. That gives chance to more people to join. On one side, the lift has a maximum capacity, so you avoid the Godzilla Anti-Pattern. And on the other side, by waiting a bit, you avoid packets that are too small. Of course, if your lift is full, you might also choose to make it leave right away without waiting for the timer to end.
This is the last of my Queue Patterns. Next time, I can move over to the Thread Patterns.

Godzilla Anti-Pattern

Last time, I presented the Santa Claus Pattern, where you would send several messages wrapped up in the same packet to lower payload and increase performance.
However, if you create your packets without discrimination, sooner or later, you’ll meet Godzilla, the packet of monstrous size. Sending huge packets on your intranet can have quite a bad effects on all the other applications of your ecosystem. Some communication frameworks even forbid packets that are too big. For instance, I recently met Godzilla in a system using Weblogic, where maximum packet size is set to 50MB by default. Even more recently, I met a similar case with OmniOrb.

On a User Interface, big packets will make your windows seem to freeze. Although the processor is working at full speed to handle all your messages, the repaint will happen only after the whole packet is handled, and the user will not understand why nothing happens on the screen.

The way to handle Godzilla is of course to set a limit to the size of your packets. If we take the code from Santa Claus, a simple modification will help you avoid Godzilla:

private void sendData() {
  if (!queue.isEmpty()) {
    List<Message> packet = new ArrayList<>();
    queue.drainTo(packet, MAX_PACKET_SIZE);
    sendPacket(packet);
  }
}

As a way to fight both Godzilla and its opposite, next time I’ll show the Opera Lift Pattern.

Santa Claus Pattern

In a previous post, I talked about the Water Drop Anti-Pattern, where the ratio of payload to data was leading to poor performances. A way to alleviate this problem is to introduce the Santa Claus Pattern. Like Santa Claus, we will make packets. But instead of packing presents, we will pack several data messages into a bigger one. This way, the payload of sending this packet on the intranet will be insignificant compared to the useful data. Also, for a user interface, we will spare several repaints, leading to better performance.

There are of course several ways to implement this pattern. A possible solution is to use a timer:
 
 public void init() {
  executor = Executors.newSingleThreadScheduledExecutor();
    executor.scheduleAtFixedRate(this::sendData, DELAY, DELAY,
TimeUnit.SECONDS);
} 
private void sendData() { 
if (!queue.isEmpty()) {
List<Message> packet = new ArrayList<>();
queue.drainTo(packet);
sendPacket(packet);
}
}


But be careful with this pattern, as you might wake up the Godzilla Anti-Pattern!

My first steps with Java 9

Java 9 is finally out! So I decided, as a first approach, to try and start our main application with it, just like this, without any re-compilation.

A Dance of Flags

First things that need correcting are the start-up JVM flags. Some changed names, other simply disappeared. A good thing that the JVM helps us with explicit error messages.
In my case, I had to remove the -XX :+PrintGCDetails and -X :++PrintGCDateStamps flags, which do not exist anymore with the G1 garbage collector. I also had to replace the -Xloggc :gc.log with that one: -Xlog:gc:gc.log.

BootClassPath no more

My first surprise came from the disappearance of the BootClassPath. Of course, I heard about it, and I felt lucky that we migrated a couple of years ago from Orbix, a CORBA implementation (yes, this technology is still in use in 2017…) that installs its libraries in the BootClassPath, to JacOrb. But even without any hint of a BootClassPath in the command line, it still managed to bite me.
When we start our application, we display useful pieces of information about the environment in the log file. You can find there the command line, for instance, or the classpath. And of course, the famed BootClassPath. It turned out that the method we use for retrieving it, RuntimeMXBean.getBootClassPath(), is now throwing an UnsupportedOperationException.

What Java version again?

One try/catch later, I stumbled into the change of version number. We are moving from java version ‘1.8.0_111’ to version ‘9’. Once again, in spite of being well aware of this change, it still got me. I had commented out beforehand the part of our code that was forbidding our program to run with anything else than Java 8 (internal politics…), telling myself that I would go back to it later and try to use the all new java.lang.Runtime.Version class.
However, the problem came from an external library called Docking Frame. It tried for some reason to discover with which java version the application is running. I found myself facing an ArrayIndexOutOfBoundsException. Fortunately, someone else already solved this bug in the library's latest release. I only had to update its version.

The Forbidden Packages

Now, Java 9 forbids us to access any class coming from the sun.* or com.sun.* packages. And we are using 2 such classes in our application. The first case was easy to fix. I replaced this code:
if (UIManager.getLookAndFeel() instanceof WindowsClassicLookAndFeel)
With that one :
if ("Windows Classic".equals(UIManager.getLookAndFeel().getName()))

The second case was harder to fix. We are using the ToolkitImage class for its quite practical getBufferedImage() method. I found a replacement in the javax.imageio package.

Modules put to rest

All this was just a warm up. My next hurdle came in the shape of a NoClassDefFoundError for a class that is actually inside the JDK, more precisely in the java.corba package. As it turned out, some Modules are never loaded at start-up, probably because they are deemed as rare, or too “JEE”. And CORBA falls into that category. To solve that problem, I needed to add a ‘--add-modules java.corba’ flag to the command line.
In fact, we are using other such Modules, such as java.xml.bind or java.activation. So I decided, against all good practice described in the Java 9 Migration Guide (https://docs.oracle.com/javase/9/migrate/toc.htm), to use the ‘--add-modules ALL-SYSTEM’ flag. Of course, this is only a temporary solution…

Module Patching

Great! We have now CORBA Modules loaded, but JacOrb doesn’t seem happy. It looks for several classes in the omg.corba package, which belongs to Java, but those classes are nowhere in sight. The explanation is to be found in the omg-jacorb.jar library, bundled with JacOrb release, and that declares some of its classes in the Java package. Of course, now, this is all forbidden. You cannot declare anymore classes in a package that does not belong to you.
But you can patch a Module. This is easy, you just add a new flag to the runtime: --patch-module java.corba=omg-jacorb.jar.

Invisible Packages

Unfortunately, patching a Module is not quite enough. Indeed, many packages are not exported in the java.corba Module, because they are for internal use only. But accessing internal classes is actually the reason why JacOrb reverts to declaring its classes in the omg.corba package. So I have to declare, one by one, all the sub-packages to which it need access.
That is quite a long and painful process, where I’d add a flag, start the application, check the next exception, then add a flag again… At the end, I had to declare around ten packages with flags similar to this one: --add-exports java.corba/org.omg.GIOP=ALL-UNNAMED. It translates to: « Dear Java, could you kindly make the org.omb.GIOP package from the java.corba module visible to all the classes loaded by the classpath? »

Java is 64 bits

One last hurdle and I’ll be finished. Java is released in 64 bits version only. And our application is loading a 32 bits DLL. That makes our application crash. As luck would have it, this DLL was not needed anymore thanks to a recent migration to a full java version of an external library. We just never came around to remove the dependency.

Done!

That’s it! I did it. I have a Java 9 compatible application. It was not trivial, I had to add several flags to the command line. But most of the hard work was due to libraries that were not ready. My next step: a java 9 compilation. But that’s for another time.