GeeCON 2014

co-author: Johan Haleby

Last week we visited the GeeCON conference in Krakow as speakers and participants. The event attracted some 1200 visitors according to the organizers, and it was located inside a cinema complex a few kilometers from the city centre, which means nice chairs and a large screens. In this blog we will present a short summary of some of the interesting talks.

Testing & Deploying Microservices (Sam Newman)

According to Sam a microservice is a set of small grained services that communicate over language agnostic APIs. They are mainly structured around business needs and not technical needs (or at least business needs have higher priority). They should of course be small, usually 1000 lines of code or less (aim at 500). What microservices allows us to do is to align the software with the organization to:

• Release one system without taking down other systems
• Experiment without having impact on other services
• Scaling a component independently

It’s however not a free lunch. For example testing may become problematic because they can take a long time to execute and deploy. Sam went on to describe the build-pipeline where we should have faster tests executing first and slow tests later in this pipeline. External services can be stubbed using for example Mountebank. A very important aspect of microservices is the contracts between them. To test this Sam proposed using so called consumer driven contracts. A library that can help out in is Pact which is an open source project for doing consumer driven contract tests (it also generate server stub for the consumer). He ended up presenting various tools for making the local environment more production like, for example using Vagrant, Packer and Docker.

Micro-second latency logging, persistence, IPC and more (Peter Lawrey)

Peter is working in the High-frequency trading domain (which he defined as trading faster than a human can see). These systems are typically event driven and has a tight latency budget which typically excludes many traditionally databases. He started of by presenting Chronicle which offers fast embedded persistence for Java. The functionality of this database is simple and low level (by design) to keep up with the extremely low latency demands of high frequency trading (hundreds of thousand of events per second). Some programming principles are:

• GC Free
• Lock-less
• Shared memory
• Text or Binary
• Point-to-point TCP replication
• Supports thread affinity (binding threads to CPUs, round-trip is 25 ms 99% of the time

Some of the use cases for Chronicle are:

• Synchronous text logging (support exists for slf4j)
• Synchronous binary data logging
• Messaging between processes via shared memory
• Messaging across systems
• Supports micros-second timestamps across systems (fine-grained)
• Replay for production data in test

One nice feature of Chronicle is that no matter how slow the consumer is, the producer never has to wait because Chronicle stores data off-heap. This enables users to for example perform reporting once a day etc. What happens is that garbage is retained so that it is possible to delete a lot of it at the same time (not included in Chronicle so you have to do this yourself). Peter also presented another of their open source projects called HugeCollections. This datastore overwrites values instead of appending them as Chronicle does and thus is suitable for other use cases. Some of its features are:

• Persisted (by the OS)
• Embedded in multiple processes
• Supports concurrent reads and writes
• Off heap accessible without serialization
• Supports increment, compare and swap etc for certain data types
• Supports distributed locking

Project Avatar (David Delabassee)

Project Avatar is a new interesting project whose goal is to allow us to run NodeJS applications on the JEE platform. David started of by briefly introducing NodeJS and explained that it is often used to present data from a JEE application to a mobile/web client (using websockets, server-sent events, etc) and that the programming model in Project Avatar is similar to that of servlets. He then continued talking a bit about Nashorn (the new JavaScript engine in Java 8) which is 2 - 10 times faster than Rhino and is also more secure. Project Avatar sits on-top of Nashorn and another project called Avatar.js (not to confuse with Project Avatar). Avatar.js can be seen as a port of NodeJS on top of Java. According to David it is 95% compatible with NodeJS which means that we can make use of popular NodeJS libraries such as Express, async, commander etc. However, it cannot support libraries that uses the native Chrome API. Avatar.js also provides ways to invoke a callback to the event loop in NodeJS from JVM side when calling blocking operations (such as JDBC). One of the benefits of using Project Avatar is that it can leverage on the JVM for scalability. This means that it is possible to run several event loops at the same time. Project Avatar provides a built-in in-process HTTP load balancer to load balance load between services running inside the JVM. It also provides the ability to share information between event loops using either an in-memory event bus of a simple map-like API. Another thing that Project Avatar gives us is a so called model-store framework which can be seen as an ORM framework for Javascript based on JPA. However it is a pure Javascript API and does not leak JPA details to Javascript side. Project Avatar exposes REST based service so you can communicate with it from any system but to ease things for Java developers Project Avatar also provides a client framework. This client framework makes communication with the backend services simpler from Java.

High Performance Reactive Applications with Vert.x (Tim Fox)

An introductory presentation in which Tim started by defining Vert.x as “a lightweight, high performance, reactive application platform for the JVM”. He continued to explain that it is polyglot and that it currently supports Java, JavaScript, Ruby, Groovy, Jython, and later versions will also support Clojure, Scala, PHP and Ceylon. Moreover, supports many different ways of communication such as HTTP / HTTPS, TCP / SSL, WebSocket, SockJS, file system, event bus and recently added DNS and UDP. Core concepts:

• Verticle is an execution unit. It is single threaded, and a Vert.x instance can execute many verticles concurrently. A Vert.x application may have many verticles that communicates using the Vert.x event bus, similar to how the actor model work. Different verticles may be implemented in different programming languages.
• The event bus is the nervous system of Vert.x. It supports both point to point communication as well as pub / sub messaging. The data to be transfered may consist of strings, buffer and primitive types. For more complex data types, JSON is the preferred data type, because all programming languages have good support libraries serialization and deserialization. An interesting feature of the event bus is that it can be used in the browser as well, which means that you can use the same API when you implement your client.
• Modules consists of zero or more verticles that are packaged together, e.g. MongoDB, JDBC, FaceBook, Jersey, Spring to name a few. Vert.x modules can be stored in Maven repositories, and there is a module registry available on the Vert.x site.

Docker - intro to a revolution (Marek Goldmann)

Another introductory seminar in which Docker was presented. Docker is marketed as “lightweight, portable, self-sufficient container” (especially compared to traditional VMs). Some important concepts:

• Image - a read only template that contains information such as which operating system should be used, Java installation, Tomcat, etc. Can have a parent image. Does not have state.
• Container - a running image, have state.
• Dockerfile - a recipe for creating images.
• Registry - a place where images are hosted or shared.

One advantage of using Docker is that you can use the same image for the entire lifecycle of application development. The developers can use it when they implement new features, the build server can use it when performing integration tests, it can be used both in staging and production environment. By minimizing the number of moving parts due to different environments and / or configurations, the distance between Dev and Ops is decreased and consequently also the number of bugs.

Custom Assertions In Tests (Tomek Kaczanowski)

This lightning talk was about how to make custom assertions using AssertJ. The short session was basically a rehash of the custom assertions example at the AssertJ home page, but it was useful anyway. If you are not familiar with it, we suggest that you take a closer look and start using it in your tests.