Book Review: "Real-time Web Application Development using Vert.x 2.0"

About Vert.x

I am following the evolution of the Vert.x project since its inception and I was expecting to see some books coming about the subject sooner or later. First of all, some explanation on what's Vert.x:

"Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications."

The product is 100% open source, licensed under the business friendly Apache Software License 2.0 and well documented. The project's founder and main maintainer is Tim Fox, of HornetQ fame.
Vert.x characteristics are nicely summarized in the related Wikipedia entry:

Vert.x is a polyglot event-driven application framework that runs on the Java Virtual Machine.

Similar environments written in other programming languages include Node.js for JavaScript, Twisted for Python, Perl Object Environment for Perl, libevent for C and EventMachine for Ruby.

Vert.x exposes the API currently in Java, JavaScript, Groovy, Ruby and Python.

Scala and Clojure support is on the roadmap.

The application framework includes these features:

• Polyglot. Application components can be written in Java, JavaScript, Groovy, Ruby or Python.
• Simple concurrency model. All code is single threaded, freeing from the hassle of multi-threaded programming.
• Simple, asynchronous programming model for writing truly scalable non-blocking applications.
• Distributed event bus that spans the client and server side. The event bus even penetrates into in-browser JavaScript allowing to create so-called real-time web applications.
• Module system and public module repository, to re-use and share components.

Few days ago I decided to purchase a recent book from Packt Publishing about the subject.

The Book

Title: Real-time Web Application Development using Vert.x 2.0

Language : English

Paperback : 122 pages

Release Date : September 2013

ISBN : 1782167951

ISBN 13 : 9781782167952

Author(s) : Tero Parviainen

I bought the eBook format only and I read it in both my iPad and computer screen, especially because the narration is mainly about building a fairly complete Web application, so I wanted to read and experiment at the same time, by entering the code by hand and running it step by step.

Below I provide a short summary of the book' sections and I will write some final comments about it.

Preface

The preface introduces clearly the content and objectives of the book

"Real-Time Web Application Development using Vert.x 2.0 will show you how to build a real-time web application with Vert.x. During the course of the book, you will go from the very first "Hello, World" to publishing a fully featured application on the Internet."

The scope is to build an editor with which people can create mind maps collaboratively. So, it is neither a too trivial application, nor something too complex. A good, balanced choice, with the additional bonus of learning a few of jQuery, D3 JavaScript library and MongoDB on the road.

What the book covers 

Chapter 1, Getting Started with Vert.x, guides you through the installation of the Vert.x 2.0 platform and its prerequisites. In this chapter, you'll also write your very first Vert.x application: the web equivalent of "Hello, World".

Chapter 2, Developing a Vert.x Web Application, covers the development of a full-fledged Vert.x web application, including both the server and browser components. You will become familiar with the architecture of a typical Vert.x application.

Chapter 3, Integrating with a Database, extends the web application from the previous chapter by adding support for persisting data in a MongoDB database, using one of the available open source Vert.x modules: the MongoDB Persistor.

Chapter 4, Real-time Communication, builds on everything you've learned so far
to deliver the secret sauce: real-time communication. You will develop a real-time, collaborative, browser-based mind map editor.

Chapter 5, Polyglot Development and Modules, presents some of the polyglot features of Vert.x, as well as the development of reusable and distributable modules,
by creating a Java module that is used to save mind maps as PNG images.

Chapter 6, Deploying and Scaling Vert.x, shows how to deploy your Vert.x application on Internet, by setting up a Linux server with continuous deployment. Finally, we discuss the basics of scaling Vert.x for growing amounts of users and data. 

My comments

One might argue that the official Vert.x documentation is already quite comprehensive and this book doesn't add much, but conversely I feel this book allows for a smoother approach to learning, without the need to browse and search too much around the Web site. Maybe somebody with already a working experience with Vert.x wouldn't gain a lot of new knowledge here, at the end I feel the book is more focused on Vert.x beginners, but anyway it contains a good amount of advanced tips to make it valuable for a wide audience.

Vert.x is a polyglot framework, so one can choose among a set of popular programming languages, with even more on the move, but the code in the book is mainly Javascript, also server side. On one hand this seems to restrict a bit the potential audience, as to fully understand the source code and the logic behind the mind map application a decent knowledge of Javascript is advisable, but on the other hand this could be very appealing to node.js developers, as they could immediately compare it with Vert.x. Then, also a client-side Javascript developer can easily follow the content and learn some server-side programming. I'm not sure on my side if I would pick Javascript for developing complex server-side logic, but adopting the same language for both client and server development undoubtedly has its own advantages, as the growing popularity of node.js testifies.

What I especially like in this book is the capacity to explain "full stack" concepts in small, easy steps. You learn about Vert.x and asynchronous message exchanges via the event bus, but also some client side programming techniques in Javascript. The bridge between client and server is built using the SockJS library, which provides real-time, full duplex, client-server communication through HTML5 WebSockets and other fallback mechanisms for older browsers.

Another plus of this book resides in its two last chapters, about modules and deployment. Chapter 5 provides a clear description of distributing and managing Vert.x applications through modules, while Chapter 6 goes into the fundamental topic of real deployment and scaling of Vert.x applications. As Vert.x applications are not distributed as standard Java EE packages, these final chapters are really a bonus and I wish to see more books that include at least some basic information about development, scaling and lifecycle management.

Conclusions

The book is very well written and readable. It is balanced, as it can support both the novice and the expert developer in exploring this excellent Web framework. I can definitely recommend buying it if you want to start studying in deep Vert.x.

Note: I actually bought this book by myself and not asked to review it by Packt or anybody else, so this article reflects my own independent opinion only.

References

• http://vertx.io/
• http://en.wikipedia.org/wiki/Vert.x
• http://www.packtpub.com/real-time-web-application-development-using-vert-x-2-0/book

Apache Maven Starter - my first, little book

Today Packt Publishing has published a little book I have written in the last few months together with Maurizio Pillitu.

The book is titled Apache Maven Starter and it's part of the Instant collection by Packt Publishing. Instant books are concise and focused technical guides, usually no more than 50 or 60 pages, providing the maximum amount of information in the quickest and most effective way.

Get to grips with a new technology, understand what it is and what it can do for you, and then get to work with the most important features and tasks.The book follows a starter approach for using Maven to create and build a new Java application or Web project from scratch.

I accepted the invite to write this book because, despite the huge amount of information already available on this subject, in form of other books and online material, when I started learning Maven I was searching for more concise information. The book actually doesn't aim to be a complete reference, but a place to start from and a collection of pointers to additional information. So, it is the book I wished I could read years ago.

Maven ultimately allows for the automation of the build lifecycle and independence from any IDE. You must always be able to build and test any Java project from the command line, using your favorite editor for coding. It is important to control exactly what libraries get distributed with Java projects and to have a standard project template and build process. 

Instant Apache Maven Starter will concentrate the most useful information into one single, very compact source. 

What you will learn from this book

• Download, install, and configure Apache Maven with the minimum fuss
• Make your own Java project templates and reuse them
• Deploy to Tomcat or run an embedded Tomcat with Maven
• Perform unit and integration testing with Maven and JUnit
• Manage dependencies and project coordinates, adopting best practices
• Create and manage multi-modules projects
• Use Maven from your favorite IDE: Netbeans, Eclipse, or IDEA

I want to especially thank Maurizio Pillitu and the Packt Publishing editorial team, it has been great to work together guys!

The book is already available on Amazon, Packt and Safari Online.

Fuji Simple Service API, SpringDM and OSGi Integration with JBI

Sujit Biswas wrote an interesting article which:

"[...] shows how to integrate Fuji simple service api with spring/springDM application, We will create a springDM application which instantiates the above provider Implementation , based on spring-config and spring-osgi-config files."

Fuji allows for Spring and OSGi services integration

"The simple service provides the capability to invoke/interact with JAVA code outside of JBI, i.e Service API provides a bridge between code that is hosted outside of a JBI component and service endpoints available on the NMR."

This enables integration of OSGI/POJO services with JBI. Read Sujit's article for more.

About Fuji:

"Project Fuji forms the core component of Open ESB v3 effort and represents Sun's next generation open source integration runtime, focused on providing a lightweight, developer-friendly, and extensible platform for composite application development.

At the core of Project Fuji is a lightweight micro-kernel based on JBI (JSR 208) and OSGi. Packaged as an OSGi bundle, the micro-kernel can be installed in any OSGi R4 compliant runtime (such as Felix, Knopflerfish or Equinox), including GlassFish v3. JSR 208 support introduces a robust, message-based service bus to the OSGi environment and allows the wide range of existing JBI "components" (adapters and containers) to run in Fuji.

Developer experience is a primary focal point in Fuji as evidenced by the level of flexibility and accessibility offered in the platform. Starting with a rapid, top-down development language, IFL (Integration Flow Language), developers can quickly and easily generate an integration application using a domain-specific grammar. The service development model favors convention and configuration over boilerplate code and framework APIs, allowing integration developers to focus on the code that matters. "

A Java CAPS Custom Security Provider Enablement

Recently I had to enable a Java custom security provider implemented by a customer. The implementation is based on a set of JAR files included into Java Collaborations, providing some special signing and hashing security features.
To have that libraries working I just had to add few lines to the server.policy file, which resides into:

logicalhost\is\domains\domain1\config

being domain1 my target domain. The JAR files were put into

logicalhost\is\domains\domain1\lib\ext

Below the additional permissions fragment:

// Basic set of required permissions granted to all remaining code
grant {
    ...
    // Java CAPS needs these permissions so that the Bouncy Castle provider can be used
    permission java.security.SecurityPermission "insertProvider.BC";
    permission java.security.SecurityPermission "removeProvider.BC";
    permission java.security.SecurityPermission "putProviderProperty.BC";
    
    //----------------------------------------------------------------------------
    //  "InnoSec" custom security provider
    //----------------------------------------------------------------------------
    permission java.security.SecurityPermission "insertProvider.InnoSec";
    permission java.security.SecurityPermission "removeProvider.InnoSec";
    permission java.security.SecurityPermission "putProviderProperty.InnoSec";
    //----------------------------------------------------------------------------
    ...

java.lang.OutOfMemoryError: unable to create new native thread

Symptoms

Some days ago a flow running into JCAPS 5.1 produced this exception:

java.lang.OutOfMemoryError: unable to create new native thread

The first attempt, especially if you are used to ICAN 5.0, would be to add memory to the JVM's heap with the -Xmx flag. But forget for a while about the misleading "OutOfMemoryError" and focus to the rest of the message: it is clearly telling that the JVM was asking the O.S. to create a native thread, but that was not possible. It does not mean you don't have enough heap. In fact, the mentioned flow was already running into a Logicalhost with 1024 Mb of memory and there was no sign that it was not enough.

Diagnosis

Depending on your operating system and JVM version, you can have a pretty different per-thread stack size which affects both the maximum number of native threads you can start and the overall consumed memory. See the Java HotSpot VM Options:

Thread Stack Size (in Kbytes). (0 means use default stack size)
Sparc: 512;
Solaris x86: 320 (was 256 prior in 5.0 and earlier);
Sparc 64 bit: 1024;
Linux amd64: 1024 (was 0 in 5.0 and earlier);
all others 0.

When your application is trying to start too many threads you might need to decrease the default stack assigned to each thread using the -Xss parameter, so that each single thread has less stack but you can create more of them. For some operating systems this is not enough, you should decrease the O.S stack size using the "ulimit -s" command.

Currently, some stack sizes are:

           ThreadSS  VMThreadSS  CompilerThreadSS   default_stack_size
                    
SPARC 32       512K      0  C2:2048K   C1:0      not used
SPARC 64      1024K      0  C2:2048K   C1:0      not used
Solaris i486   256K      0  C2:2048K   C1:0      not used
                       
Linux i486       0       0  0                      512K
Linux ia64       0       0  0                     1024K
                
Win32 i486       0       0  0  ASSERTs:1024K         0
Win32 ia64       0       0  0  ASSERTs:1024K         0

Notes:
  1) 0 for VMThreadSS and CompilerThreadSS implies
     use of ThreadSS value

  2) 0 for ThreadSS implies use of default_stack_size

Generally speaking you should usually start testing your flows with a little JVM heap, the default JCAPS 512 Mb is normally enough. Then you should increase step by step this value only and only if your processes are allocating big data structures requiring more heap. A good step size could be 256 Mb. It is never a brilliant idea to set your domain's heap to, say, 1.5 Gb by default only because this seems to let you sleep well. Additionally to the mentioned thread problem a bigger heap will lead to more complex and longer garbage collection cycles, penalizing performances in the medium term. It is then a good idea to set the same value for -Xms and -Xmx to help the GC.

Singleton pattern and Double-Checked Locking problem

Double-Checked Locking is widely cited and used as an efficient method for implementing lazy initialization in a multithreaded environment.
Unfortunately, it will not work reliably in a platform independent way when implemented in Java [...]
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

All programming languages have their share of idioms. Many are useful to know and use, and programmers spend valuable time creating, learning, and implementing them. The problem is that some idioms are later proven not to be all that they were purported, or to simply not work as described. The Java programming language contains several useful programming idioms. It also contains some that further study has shown should not be used. Double-checked locking is one such idiom that should never be used. In this article, Peter Haggar examines the roots of the double-checked locking idiom, why it was developed, and why it doesn't work.
http://www-128.ibm.com/developerworks/java/library/j-dcl.html

I think the problem with DCL comes from checking the wrong variable. Instead of checking the static instance itself one should check a boolean, which is by nature an atomic operation. This would prevent the mentioned JVM memory model "problem". What do you think?

public class Singleton {

 private static Singleton _instance = null;
 private static boolean _initialized = false;

 private Singleton() {
 }

 public static Singleton getInstance() {
     if (!_initialized) {
         synchronized (Singleton.class) {
             if (!_initialized) {
                 _instance = new Singleton();
                 _initialized = true;
             }
         }
     }
     return _instance;
 }

}