Christopher Batey | Devoxx

Christopher Batey
Christopher Batey Twitter

From Freelance

Christopher (@chbatey) is a freelance software engineer. He is currently working as a Principal Software Engineer at Sky on a large project that is making use of non-blocking tools and frameworks within containers to vastly reduce the number of servers required to service millions of users. Likes: Scala, Java, the JVM, Akka, distributed databases, XP, TDD, Pairing. Hates: Untested software, code ownership. You can checkout his blog at: http://christopher-batey.blogspot.co.uk/.

Blog: http://christopher-batey.blogspot.co.uk/

cloud Cloud, Containers & Infrastructure

The JVM and Docker, a good idea?

Conference

Containers are the latest hype. It goes without saying that Docker for the development environment is a good thing but what about running our production Java applications inside a container?

One of the well known benefits of containers is that they provide a self-contained way to package and ship applications. However, it is already common practice to build fat executable jars that require only a JRE so what advantages would containers actually offer a pure Java shop? At Sky our motivation is efficient utilisation of hardware. We used to run single purpose VMs, which makes sense for production but for our countless test environments it is prohibitively expensive. Even IaaS is still too slow to provision new environments and bootstrap new applications. This talk will be focusing on the downsides and lessons learned from running JVMs inside containers.

We will cover the following topics:

  • The benefits, downsides and complexities of running a Java application inside a container.
  • Tuning memory limits taking into account Heap, Native memory, Metaspace, Stacks to avoid being OOM killed
  • Tracking native memory with jcmd
  • Operating system tools that are/are not container aware
java Java, JVM, Java SE/EE

The Java developers' guide to asynchronous programming

Conference

Blocking/synchronous programming has been the norm in Java. However this programming model has a major limitation: it requires one thread per concurrent request. This means that the number of requests you can process concurrently cannot exceed the number of threads, which limits scaling. This talk will explore how an asynchronous programming model can be used to avoid this limitation.

After an introduction to asynchronous design, there will be a live coding session where we will build an example service that makes concurrent calls.

We will cover the following tools:

  • The Java Future
  • New in Java 8: The CompletableFuture
  • RxJava Observables
  • The async Servlet, Spring and JAX-RS APIs
  • The Ratpack Promise

The see the following patterns:

  • Merging multiple calls into a single result
  • Returning a result when a subset of multiple calls return without blocking waiting for the rest (e.g. saving an audit log without blocking the user request)
  • Executing multiple calls and creating a result from the one that returns first

By the end of the session you should be aware of the popular tools you have for non-blocking programming in Java and when and why you should use them.