DEV Community: María Arias de Reyna

How is Leyden improving Java Performance? Part 3 of 3

María Arias de Reyna — Tue, 17 Mar 2026 11:20:00 +0000

In part 1 of this series of 3 blog posts we introduced the specific performance challenges OpenJDK faces lowering application ‘startup’, ‘warmup’ and ‘initial footprint’ costs and provided an overview of what Leyden is doing to address those challenges.

Part 2 described how to use the new capabilities offered by Leyden and presented test results which show that very significant progress has already been made and is set to continue.

Part 3 provides a more detailed account of how Leyden’s proposed solution operates and presents a first look at tooling that allows you to assess the benefits that result and tune your application to make the most of what Leyden offers.

What is inside the Ahead of Time Cache?

Ideally, an AOT cache would simply include everything needed to allow a production run to skip straight through to its warmed up state. However, in practice training runs don’t always cover all the things that can happen at runtime and hence that the assets contained in any generated AOT cache will be more or less complete.

In order to have some idea of how effective a training run has been it’s helpful to be able to look at a cache and see what is in it. Full details of the tooling that allows you to do that are presented in part 3 of this blog series. However, in order to prepare for that, we need to provide an overview of the JVM assets that end up in the cache and how the JVM uses them. We will follow up with some examples to show how effectively this improves startup and warmup.

So, let’s take a deeper look at what exactly is inside the AOT Cache. There are several different ways of classifying the contents:

The most straightforward way to classify AOT cache assets is to distinguish between Static and Dynamic data.

Static assets are data that are available in or directly derived from bytecode, data that exist, even if only implicitly, at build time.

Dynamic assets are data that get generated, or are collected, at runtime as a side-effect of execution. Some of them record information that can be used to trigger compilation and drive feedback-driven optimizations, including speculative optimization, beyond what an ahead-of-time compiler would be able to do. They can also include the compiled code that is generated as a result of that compilation.

Finally, they include training data, created as a training run progresses to track what the JVM has done and why. Training data identify what JVM assets need to be stored into the cache when it is created. They are also installed in the cache, indexing the other assets and helping identify how to use them in production.

We can also distinguish two types of data depending on their purpose:

On one hand, there is the JVM data — metadata, heap data and code. This is a network of C++ objects that are used during normal JVM running to define and regulate Java execution. These objects must always exist, even when running without a cache, in order for the JVM to be able to run an app. This object network needs to be dumped to the archive on disk in a format that allows it to be quickly and correctly restored to the relevant memory areas of the production JVM in a valid (C++ Object) format and layout that matches the JVM’s expectations.

On the other hand we also have Leyden’s own Cache Management Data, i.e. training data, which exists specifically to support creation and consumption of AOT cache. Training data are also saved and restored as C++ object data but the format and layout of these objects is determined solely by the Leyden cache management code. Its sole purpose is to track and regulate what assets get written to the AOT cache after training completes and what assets can or should be restored in production.

Let’s see in detail what each data type means.

JVM Metadata

Metadata stored in the AOT cache is a superset of what was stored in a CDS archive. The subset which overlaps with CDS is the static metadata. The latter represents the structure and hierarchy of classes in JDK and application code. Primarily, it helps avoid the cost of parsing bytecode, as it is in the same format as the JVM’s own internal metadata model: classes, methods, fields, inheritance between classes,... which can be mapped directly into memory. Having this information stored in the cache speeds up the time the Hotspot takes to decode the different class files, and to build the dependency graph.

While starting the application, the Java Heap memory gets filled with objects and instances that are going to be used during runtime. Some of those heap data objects can be cached too because they are quite predictable, like Strings hardcoded in the source code, java.lang.Class instances, some content of class static fields, objects needed to run lambdas, the class graph module,... Those are all assets that are created in memory in the same way on every run.

The heap data cached at the moment is restricted to very specific cases as it has to behave exactly the same on each and every run, but the type of data cached is expanding on each JDK version.

JVM Profile and Linkage Data

The cache also includes dynamic JVM metadata i.e. MethodCounter, MethodData and ConstantPoolCache objects. These objects are created and attached to the static metadata methods and classes and their content is updated as a side-effect of executing method code.

MethodCounter objects track how often the method they are attached to has been called. They are primarily used to trigger compilation via the baseline (C1) or optimizing (C2) compiler. The interpreter increments a method’s call count up to a threshold before scheduling a C1 compile, possibly including code that gathers further profile information. Instrumentation code in (Tier 2 andImage description 3) C1 compiled methods also updates the call count and when a higher threshold is reached either upgrades to (Tier 4) C2 compiled code or reverts to (Tier 1) C1 compiled code which includes no instrumentation

MethodProfile objects record detailed information about their associated method’s hot and cold paths, argument types and other details of how it executes, most notably any history of speculative deoptimization. Apart from the deoptimization case, which applies for both C1 and C2 code, MethodProfile objects only receive updates via instrumentation code in (Tier 2 and 3) C1 compiled methods.

ConstantPoolCache objects are attached to a clasImage descriptions and track the linkage of call and field access sites in any of the class’s methods. Prelinking avoids work at the first call or first field access and this is especially valuable when the call is an invokedynamic i.e. the bytecode that implements a lambda invocation.

Linking a lambda involves running Java ‘bootstrap’ code that identifies a private class that owns the bytecode for the lambda body, asking it to construct and return a MethodHandle that can be used to execute the target. If a lambda can be run during training then the target class and method can be pre-loaded and the MethodHandle stored in the heap and linked from the ConstantPoolCache, avoiding the need to run the ‘bootstrap’ in production. If the lambda is executed repeatedly in production the called bytecode may even be inlined into the compiled code for the caller. Effectively, executing as lambda in training removes all setup overheads in production, making lambdas as cheap to use as a direct method call.

JVM Code and Code Management Data

AdapterHandlers are a set of utilities used by the Hotspot to marshall method parameters when performing certain types of call. AdapterHandlers can be cached, avoiding the need to generate them on demand. They are identified by their AdapterFingerprint and indexed via a table of AdapterHandleEntry objects.

Alongside these handlers various StubBlobs needed by the runtime are also cached. These blobs contain JITted code that implements one or more ‘stub’ routines. Stub routines include architecture- and OS-specific code used by the JVM to perform operations that are hard to write in a platform agnostic way. Examples include: flushing code regions after update by the JIT or call linker, unwinding the stack when an exception occurs, replacing a compiled stackframe with one or more interpreter frames when execution of a deopt trap forces a bail-out etc. There are also many stubs that provide hand crafted, high-performance implementations of math, crypto or memory copy methods that are used in place of Java implementations on some architectures, especially where hand-crafted code can use specialized hardware instructions to outperform the JIT compiler. Much of the stub and adapter code has to be generated before the JDK can fully startup. Storing it in the cache and reloading it in production provides a small but noticeable performance improvement.

Leyden premain also includes CompiledMethods, i.e. pre-compiled Java methods, in the cache. This includes both C1 and C2 (Tiers 1 - 4) and in some cases different tier compiled versions of the same method. Having compiled code immediately available, especially Tier 4 code, is an enormous boost to performance. Lower tier code may be useful when the method only reached that tier during training or as a fallback if we need to deoptimize and reprofile. Pre-compiled Java methods are an enhancement we expect to add soon to the mainline JDK.

Leyden Training Data

Training data is part of the Leyden specific code. It tracks which methods have actually been loaded, executed, and used during the training run and how they have been used. Normally all loaded classes have associated class training data, but these may be omitted if, say, the class is loaded by a custom (user-defined) loader, is modified by an agent or fails to resolve because of linkage errors.There is a usage threshold which means that only methods that have been executed above that threshold will have associated method training data. Likewise, compiled method training data only exists for methods actually compiled during training. This helps both in keeping a smaller footprint in the cache and removing less useful data so processing the cache is faster.

How Do I Know Leyden Is Helping?

Depending on how well you train your deployment you may see different improvements in time to reach application start (startup time) and time to reach peak performance (warmup time). Log output is one useful way to measure these two metrics but the details will depend on what monitoring capabilities are available in your test or production environment. However, simply measuring these two times (or even recording warmup profiles) doesn’t help with the problem of explaining why, for some given training regime, you get a specific improvement or perhaps, in some cases, no measurable improvement.

For any given AOT cache (or set of alternative caches) it is very helpful to have some idea of what assets were included or excluded in the training set, which ones were written into the cache and what benefit they provide during a production run. In particular, it is useful to have both aggregate statistics and information on individual assets and their relationships. The Leyden project has provided a tool precisely to address these needs. Let's see a practical example of how to diagnose an AOT Cache.

For the purpose of this article, we are going to use the following example application: https://github.com/Delawen/bad-good-cache

This is a web application that has a simple API and a basic html interface to use it.

The first thing we need to do is to compile this application on the root folder:

$ mvn clean package

Training the application

Once we have the jar created, we use it to start a training run:

$ java -XX:AOTCacheOutput=target/app.aot -Xlog:aot+map=trace,aot+map+oops=trace:file=target/aot.map:none:filesize=0 -Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*=warning:file=target/training.log:level,tags -jar target/quarkus-app/quarkus-run.jar

The arguments we are going to use are the following:

-XX:AOTCacheOutput=target/app.aot Which will create an AOT file called app.aot
-Xlog:aot+map=trace,aot+map+oops=trace:file=target/aot.map:none:filesize=0 Which will create a map file that indexes and describes the previously created AOT file.
-Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*=warning:file=target/training.log:level,tags Which will generate training log files with relevant information

To help us train the application, we are going to use the oha\ tool, that helps us run a series of requests that will showcase a user using the application:

$ oha --urls-from-file src/main/resources/urls.txt -n 100

Now that we have trained the application, let's stop it with ctrl+c. It will take some time to stop while it builds the cache. It will do both the training and assembly steps at once.

We should have created three types of files:

target/app.aot : The AOT cache itself
target/aot.map : The map file
target/training.log : The logs for the training run

Now that we have the AOT cache, we can start a production run, in which we will also save log files:

$ exit

The arguments we are going to use are the following:

-XX:AOTCache=target/app.aot Make use of the AOT file called app.aot
-Xlog:class+load=info,aot+resolve*=trace,aot+codecache+exit=debug,aot*=warning:file=target/production.log:level,tags Which will generate a production log file with relevant information

And we can use the application normally. Let's play a bit on http://localhost:8080/

On this run, we created the production.log file.

Analyzing the Cache

After using it, we can stop it and analyze how the AOT Cache behaved with our AOT Cache diagnostics tool: https://github.com/Delawen/leyden-analyzer

The first step is loading all the information into the tool, to run a proper analysis:

> load aotCache --background target/aot.map

> load trainingLog --background target/training.log*

> load productionLog --background target/production.log*

Now we are ready to start our analysis. A good place to start is the info command that shows a summarized version of what is inside the cache:

Are we training the right thing?

The first thing that should catch our attention is that there's more than 10% of classes that were used on the production run but were not cached. That's not usual, so let's dig into whatImage description those classes are. There are hundreds of them, so if we filter by our package name, that would make our exploration easier:

What does this mean? Let's take a closer look:

This class was not loaded during training but it was loaded during production. Something went wrong with our training.

We can explore the class org.cutecats.rest.json.CatPhotoGenerator by looking at the source code. There, we discover that it should be used by org.cutecats.rest.json.CatResource.

So, this class was loaded both on training and production runs, and the metadata is included in the AOT Cache. But for some reason, none of its methods were profiled during the training run. This means that our training run did not make extensive use of this class. Maybe we should take a look at our training run.

And indeed, there is an obvious mistake: the urls.txt file that oha used to create the requests only contains the static html pages. None of our Java classes are executed, although Quarkus loaded them at the beginning as services.

Let's run again the training, changing the url to the Java endpoints instead of the html pages: http://localhost:8080/cats and http://localhost:8080/list

Don't forget to remove the log and aot files from target/ after each try to have clean runs (the clean on the maven command should do that).

If we analyze the results again with our tool, we should see a different result:

We have increased the percentage of the classes used (96%) in production that were cached compared to our last attempt (89%). That's an improvement.

Did we load all relevant classes during Training?

Let's check again for classes loaded in production that were not cached:

Something is still not working as intended. Maybe we should approach this from the other side: are we executing some testing code that replaces the real production code that should be executed during training?

Let's check if there's something being stored in the cache that we don't really need:

We can see a suspicious class called DummyPhotoGenerator. That's supposed to be used only for testing purposes, not for real training and production. Using DummyPhotoGenerator instead of the CatPhotoGenerator class is making the code and classes used by CatPhotoGenerator not being used. If we explore our source code, we will discover that there is a “test” argument on the /cats endpoint that distinguishes between testing and production.

To fix our training, we have to call the endpoint /cats with a test=false argument. Because the training run is not a test run.

The training run has to be as close to production as possible. If we use test classes, not only will they be stored in the cache and be loaded on production run, but they may also hide real production code from being trained.

Let's try again, now using http://localhost:8080/cats?test=false in the urls.txt file.

We have increased a bit more the percentage of classes loaded, which is always a good sign.
Image description
Do we have any other classes loaded during production that were not cached during training?
Are there any testing classes loaded during training or production runs?

We made sure that:

- All our classes used in production are included in the cache

- None of our testing classes are included in the cache

Although we still don't have the aspiring ideal 100% classes cached, we are really close (98%) and we can be happy with the list of classes cached. We can now focus on how good the profiling of the methods is.

Are our methods properly trained?

Maybe you already noticed another important information we have been ignoring until now: all our classes are labelled as "[Untrained]". Let's take a closer look at that.

Profiling is done on each method independently, so let's take a look at one of our methods that we know should be well trained. The describe command is pretty self explanatory on this case:

Let's follow the recommendation and do more requests during the training run.

$ oha --urls-from-file src/main/resources/urls.txt -n 10k

And with 10 000 requests done, we can see that we got our method completely profiled and compiled to the higher level:

There’s still more improvements that can be done to the training that will greatly depend on your application, but now we have all the basics covered.

How is Leyden improving Java Performance? Part 2 of 3

María Arias de Reyna — Tue, 17 Mar 2026 11:10:00 +0000

Part 2 describes how to use the new AOT capabilities offered by Leyden and presents test results which show that very significant progress has already been made and is set to continue.

Part 3 provides a more detailed account of how Leyden’s proposed solution operates, and offers a first look at tooling that allows you to assess the benefits that result and tune your application to make the most of what Leyden offers.

How to use an AOT Cache

To use an AOT cache (on JDK 25+), you need to add some JVM arguments to your app launch command. There are two ways of doing it, in 2 or 3 steps.

Joint Training and Assembly steps — writing of the AOT cache is performed in a forked Java runtime at training run exit:

Training+Assembly Run: java -XX:AOTCacheOutput=${aot-cache-file} -jar app.jar
Production Run: java -XX:AOTCache=${aot-cache-file} -jar app.jar

Step 1 of the two step model runs your application until it exits (whether by means of some exit mechanism built into the application or simply by typing Ctrl-C on the console). At that point a separate Assembly JVM is forked to consume the training data collected during the training run and generate an AOT cache using the name supplied via the AOTCache command line option. The training JVM waits for the Assembly JVM to finish writing this file before it completes its own exit.

Step 2 runs the production application using the AOT cache specified by the AOTCache command line option.

Separate Training and Assembly steps — allows the assembly run to be executed independently without delaying the training run exit:

Training Run: java - XX:AOTMode=record -XX:AOTConfiguration=${aot-cache-conf-file} -jar app.jar
Assembly Run: java -XX:AOTMode=create -XX:AOTConfiguration=${aot-cache-conf-file} -XX:AOTCacheOutput=${aot-cache-file} -jar app.jar
Production Run: java -XX:AOTCache=${aot-cache-file} -jar app.jar

The three step model allows you to manage training and assembly as independent steps.

Step 1 runs your application until it exits, at which the training data collected during the training run is dumped to an AOT configuration file specified using the AOTConfiguration command line option.

In step 2 this training data is passed to a new JVM using the same command line option and is used to generate an AOT cache to the file specified using the AOTCacheOutput command line option.

Step 3 runs the production application using the AOT cache specified by the AOTCache command line option.

The 3 step workflow is sometimes preferable because it allows the training JVM to exit more quickly. Dumping of training data is usually quick even if it is not instantaneous. Generation of the AOT cache takes substantially longer because there is a lot more work involved in sorting and laying out that data in a format that meets the JVM’s needs.

Also, with the Leyden premain release, the Assembly JVM will perform a ‘cleanroom’ compilation of all the methods to be included in the cache, possibly compiling them at more than one compilation level. This adds more time to the cache generation step.

How to properly execute the Training Run?

The best way to train your application and generate the AOT cache is a canary deployment, where you run your application in the real production environment with training enabled, allowing it to collect training data as it runs. However, that’s not always feasible, especially on containerized production environments that don’t have disk-write privileges.

Depending on how your deployment is set up this may be the type of circumstance where you choose the 3 step training model, allowing your training JVM to exit quickly and relegating the assembly to a separate, follow-on deployment. Note that the assembly JVM does not run your application code so will not need access to resources like networks or databases.

Recording requests made to your application and replaying them on a test server (either in real time or delayed), is also a very good way to generate the AOT cache, as it reproduces exactly the same kind of behaviour you can expect on production. Alternatively, you can generate synthetic request data that simulates the behaviour you expect to encounter in real production, although that may reduce the relevance or accuracy of the resulting AOT cache assets.

If you have a strong testing framework, and you are using Quarkus, you can always generate the AOT cache using integration tests. Note that you will need to run the methods repeatedly (probably several thousands of calls) to generate the proper compilation optimizations.

The best results arise when the raining run resembles a production run as closely as possible. However, whatever training method you employ, on any cache produced will only be usable in production if you run with the same JVM and the same command line JVM options.

You can add extra jars at the end of the production run classpath but the initial segment must be the same as the classpath provided during training.

At the moment of writing this article, you also need to deploy on the same CPU family and operating system. In upcoming versions which will include compiled code in the cache, the production hardware must implement the exact same CPU features as the hardware used for the training run. If the CPU features are not identical then compiled and stub code assets will be ignored (other cache assets will still be usable).

Remember to follow these basic constraints when generating the cache: same hardware, same Java version, same Operating System, and same JVM arguments.

Should I start using AOT Cache in Java already?

The short answer is yes.

Whether your application gets significantly faster now, or if you are interested in testing it to help Leyden development move towards your interests, you should start using the AOT cache already.

Note that you need at least JDK 25 to be able to use it. Performance gains are incremental with each new JDK release. The actual improvements that you can achieve using Leyden depend strongly on your application and how you use it.

Let’s see some examples. We are going to run them over JDK 26.

Heavy Mathematical Example

First we are going to use a benchmark application that runs heavy mathematical operations via a REST API. We are going to train this application twice to compare how different training affects performance on production.

This application makes use of an aot-jar from Quarkus which is optimized for Leyden and available since version 3.32.0.

We are going to use a training run that randomly calls the following urls:

/nqueens/16 : to calculate the nqueens problem with a 16 board size
/fibonacci/100 : to calculate fibonacci series with input 100
/nqueens : to calculate the nqueens problem with either 16 or 8 as the board size
/fibonacci : to calculate fibonacci with a random number between 1 and 100

The idea is to have a load that is partly random (as an API with real users would be) but has a preference over specific branches or loop unrolling sizes.

We will do a training with 1000 requests and a second training with 60 000 requests. That should represent how different training affects final performance. We are going to run the application on a Linux machine assigning 2 cores to our application.

Due to the kind of things Java 26 is storing in the AOT cache, we can theorize that there won’t be much difference between the different trainings when comparing startup time (startup of the application and opening the port), as most of the code run during initialization is run only once, so adding more requests to the training won’t improve that initialization time. This is something that may change in future developments as more assets are included in the AOT cache.

By using the Java AOT Cache Diagnostics Tool, we can compare the contents of the cache generated on each training.

1000 requests training	60 000 requests training

As expected, both trainings seem to have cached the same amount of metadata (slightly above 99% of classes used), because the code loaded into memory on both cases should be more or less the same (some timeout or runtime exception thrown may explain differences). This means that the startup time using any of the generated caches should be similar.

The training with 60 000 requests has many more methods that are profiled and compiled at a higher level because it had a longer time to profile and optimize. That should lead to better outcomes on the warmup time.

Anyway, we should notice an improvement on startup time compared to the regular Java deployment, because we have a lot of metadata, profile and linkage data and some heap data already cached during AOT. And as we can see on the following graph, time to first response (which includes initialization) is already cut in half.

The other interesting measurement is how much and for how long response times are disrupted during the early stages of application execution. There is always some small variation in response times even when an app is fully warmed up – often referred to as jitter.

However, during warmup the housekeeping work that the JVM has to do can significantly increase jitter. Individual responses may be delayed because they require the thread to execute one-off events like load or initialize a class, link a call site or field access site, or update profile data. Background JIT compilation will also steal CPU cycles, potentially pre-empting request handling in Java threads. Finally, early requests will mostly execute relatively slowly in the interpreter, while later requests will gradually respond more quickly as the JIT compiler delivers compiled code.

In theory, this is where longer training sessions should have a bigger impact. Better training results in more cached classes and heap objects needed in production, more pre-linking of calls and accesses, more method profile data to allow earlier and better informed compilation. So, we should see not only an improvement compared to the regular java version, but also a difference between the two trained caches.

The graph above shows individual response times for requests for each of the three deployments, Traditional Java (no AOT), AOT trained with 1000 requests, and AOT trained with 60 000 requests.

In all cases, the request rate is constant and within the peak capacity of the server. In all 3 cases the jitter slowly decays as the request count increases, eventually converging to a low, random variation.

However, it is also very clear that

There is a lot more JVM housework being performed in the non-AOT case than when using AOT, reaching peak performance later.
The well trained cache suffers less jitter, i.e. removes a lot more housework, than the weakly trained app.

Note that JDK26 does store training data on the cache, but does not store compiled code. This means, future versions of the JDK will show a much larger difference between weak and strong training regimes.

Simple REST API

Now, we are going to do the same with a simple REST API application using Quarkus that connects to a database to extract data. This time we employ the Leyden premain JVM which caches code compiled code as well as all the other AOT cache assets mentioned earlier.

We use a single training run with 10 000 requests, executing a test that calls the endpoint /fruits repeatedly. In contrast with the previous example, in this case we are not going to observe as much advantage from speculative compilation because the code is simpler and the entrypoint is always called with the same parameters. But we should still see an improvement all the same.

Let’s take a look at the time to first response to see if it is improved by Leyden AOT:

Startup time in this example is slower than in the previous example because we have to initialize connections to the database and load the database model.

Now, let’s take a look at the response times and see if the warmup time is also improved thanks to the AOT cache.

Both runs suffer jitter during the first requests, at which point most of the housekeeping work is completed. The dramatic drop off in jitter for the AOT run around request 45 indicates that at this point almost all loading, initialization and linking costs have been met and the necessary compiled code has been delivered. By contrast the non-AOT run is still suffering jitter even after 100 requests i.e. it has still not warmed up to reach peak performance.

These are only a couple of examples that showcase how Leyden is already improving your startup and warmup time.

How far Leyden can help your application can only be discovered by trying it.

How is Leyden improving Java Performance? Part 1 of 3

María Arias de Reyna — Tue, 17 Mar 2026 11:00:00 +0000

In this series of 3 blog posts we will explain how OpenJDK project Leyden is helping to improve a specific area of performance where Java has notably lagged behind other languages i.e. application ‘startup’, ‘warmup’, and ‘initial footprint’.

Part 1 explains what those terms mean and why Java faces challenges in matching the behaviour of other languages. It then provides an overview of what Leyden has done to improve startup and warmup in existing JDK releases and what is planned for upcoming releases.

Part 2 describes how to use the new capabilities offered by Leyden and presents test results which show that very significant progress has already been made and is set to continue.

A Brief History of Java Performance

Java has been one of the most popular programming object-oriented languages for decades. Its success relies heavily on the fact that it offers a portable, managed runtime that makes it easy and safe to resolve many common programming challenges. In particular, Java was the first portable language to make it straightforward for programmers to deliver multi-threaded applications which allocate and manage storage at runtime without risk of invalid memory accesses.

The fact that Java remains popular still surprises some programmers, given that it belongs to the family of dynamic languages that, most notably, includes Lisp, Smalltalk and Self. Dynamic languages allow their code base to be incrementally defined as the program executes. That code base is often implemented using a language-specific virtual machine. Dynamic languages were traditionally executed by interpreting either the source code or an intermediate bytecode derived from the source. This often caused lower performance than native-compiled, non-dynamic languages.

However, modern Java runtimes rely on powerful ‘just-in-time’ (JIT) compilers to translate bytecode to native machine code at runtime. JIT compilation, a technique originally tried in Smalltalk nearly 40 years ago, has improved Java performance by orders of magnitude from the early days of an interpreter-only runtime. The use of runtime execution profiling supports feedback directed optimization and speculative optimization. This has allowed Java JIT compilers to achieve peak performance that far exceeds what can be achieved with programs that are compiled ahead-of-time (AOT).

Why Java takes time to reach peak performance

The downside of dynamic class loading and JIT compilation is that a Java runtime takes some time to achieve this impressive peak performance.

When a new Java application is launched, it is normally a ‘cold start’. Details of all the classes and methods the application needs to use are only available in a compact bytecode representation, stored on disk either in application supplied class files or embedded in the Java platform’s jmod files.The Java Virtual Machine (JVM) has to parse and unwrap this bytecode, constructing its own ‘metadata’ model of the class and method base, one that the interpreter and compiled code can efficiently operate over. It also has to set the base state of each loaded class, running Java ‘static init’ code to populate the class’s static fields, before it can execute any of the class’s methods.

In addition, the JVM has to perform dynamic linkage. When compilation or execution of a Java method first encounters a call (invoke bytecode) or a data access (get/putfield bytecode) the JVM has to link that call or data access site. That involves replacing references to the target class and method/field, which occur as symbol names in the bytecode, with a direct memory reference. This identifies first the target metadata class, and then the target metadata method or field. If the target class has not yet been encountered during execution, this linking step may trigger further bytecode loading, parsing, and class initialization.

The JVM normally starts off executing Java methods in the interpreter. Of course, it could always execute native code, compiling the Java method bytecode either immediately at load or lazily at first call. However, compilation takes time to complete so it is normally better done in the background while proceeding to interpret. Indeed, JIT compilation frequently pays off more when done selectively. Methods that only get called once or twice can take more cycles to compile than to simply interpret the bytecode.

Furthermore, without runtime execution profile data as input, the compiler is unable to make informed, feedback-directed optimizations that significantly improve performance of the compiled code. Most importantly, it cannot simplify the compiled code by speculating that previous execution patterns will continue, replacing code that lies on untaken ’cold’ branches with traps. Speculative compilation, an optimization first used in the Self compiler over 30 years ago, reduces both the size and the complexity of bytecode that feeds into a specific compilation. That, in turn, enables deep inlining of method calls and offers the possibility to identify many more derived optimizations. The rare case where a trap on a cold branch gets executed is handled by deoptimizing i.e. jumping back into the interpreter and recompiling the method with an updated branch profile.

Housekeeping considered harmful

During early stages of application execution, the JVM housekeeping overheads listed above are at their highest. Class loading and initialization, class linking, and recording of method execution profile data occur frequently as side effects of execution, for both application and JDK runtime methods, impeding direct forward progress of the application. Method compilation proceeds in dedicated, background compiler threads, but this still steals CPU cycles, once again, impeding application progress.

The impedance of JVM housekeeping work gradually decreases, as more and more of the required JDK code and application code is gradually linked into the runtime. At the same time delivery of compiled code improves application execution speed incrementally.

After some time, a steady state is reached where most or all classes are loaded and linked, most or all methods have been profiled, and all ‘hot’ methods have been compiled with highly efficient code. Very occasionally variation in input data or a phase change in program behaviour drives the application down a cold path, triggering deoptimization and incurring extra JVM overheads. However, by and large, applications mostly warm up and continue to run with steady peak performance.

Leyden Project ‘premain’ Experiment

Project Leyden has been experimenting with reducing the impedance of JVM house keeping tasks in the ‘premain’ branch of the project repository. The observation that drives the Leyden premain experiment is that, most of the time, the housekeeping operations that occur during an application run involve doing exactly or almost exactly the same work with the same result, certainly in the early stages where the impedance is high. On every run a lot of the same byecode gets loaded and linked, the same classes get initialized, the same methods turn out to be hot, and end up getting compiled with the same or very similar profile information.

This is especially true for the JDK runtime code that runs before entering the application main method, likewise for JDK library code that the application calls out to. The JVM will always load base classes like java.lang.Object, java.lang.Class, or java.util.String. The same String instances, hard coded as literals in JDK methods, are added to the heap on every single run. Container classes like List and HashTable are commonly reused for the same purposes.

JDK classes are fixed for any given release so their class, method and field metadata will always be the same and they will always cross-reference each other (i.e. be linked) in exactly the same way. In fact the Leyden premain branch gets its name from its original focus, which was optimizing this JDK execution that happens before entering application main.

The idea of profiting from this identity of JDK metadata across runs is not new. Since JDK13 Class Data Sharing (CDS) has been able to optimize away class loading and bytecode parsing for JDK classes by storing the JVM’s metadata model of the JDK classes in a CDS archive, allowing it to be reloaded ’oven-ready’ on subsequent runs.

That version of CDS provided an effective, albeit limited, limited warm-start capability for the JDK, halving the time taken for the JDK to start up i.e. complete JDK initialization and enter the application main routine. CDS also helped application warmup by lowering initial costs involved in callouts to JDK library code.

With application classes there is no strong guarantee that the same classes will be present in the same format between one run and the next. Or that classes loaded and used on one run will always be loaded and used in the same way on subsequent runs. However, so long as the same jars appear in the classpath and the class bytecode is loaded without runtime-specific agent transformations, then it is possible and, for many classes, quite probable that saved metadata will be reusable.

More recent versions of CDS have supported save and restore metadata for application classes via a dynamic CDS archive, allowing the JVM to bypass loading and bytecode parsing costs for those classes on subsequent runs, improving both application startup and warmup.

Leyden’s premain branch builds on this success but it is addressing a bigger prize than just archived metadata. The broader internal JVM state — not just metadata but static field data, linkage data, method profiles, compiled code — which is slowly constructed during warmup, may vary depending on precisely what happens on each run. However, most of what is created on one run, if it could be saved in an archive – as CDS currently does with metadata, ought to be reusable on a subsequent run, short circuiting the housekeeping overheads normally incurred to create it.

Even if some saved state might turn out not to be useful, because, say, a class was not referenced or a method not called in the subsequent run, the ability to reuse some of the state should still pay off. The cost of reloading the required state can be made much lower than the cost of recreating, meaning the application can reach peak performance earlier, with less impedance from the JVM. The more reusable state that can be saved the greater the reduction in impedance.

Training and Production Runs

So, the basic idea behind is to run your application twice:

Training Run: in which we cache the metadata, the profiling statistics, some heap data, compiled code,...
Production Run: loads the previously (ahead of time) cached information, so the run starts hot. This is the “real” run in which we make use of our app.

Of course, this only makes sense if the training run accurately represents the production run.

To achieve this, we need to respect the following constraints:

Same Hardware: Or the compiled code may not be able to run, and the optimizations made may even be against performance in our production run.
Same Java version and source code: If we change the source code, anything cached related to the source code gets deprecated and becomes useless.
Same Operative System Family: There are pieces of the JVM that behave differently on Linux, Windows or MacOS. We can’t just reuse our cached information if we change it.
Same JVM options (mostly): We could maybe change some JVM options (like use a different garbage collector). But then, profiling statistics that we cache, and information about how the application behaves, may no longer be valid to our new configuration. Better not to play with these settings.
[optional] No Custom Classloaders: The cache will ignore (for now) the classes loaded with a custom classloader. This means that part of the application will not be hot when run for the second time.

Some of the AOT improvements developed in the Leyden branch have already been made available in the latest JDK LTS version at the moment of writing this article (25). But the plan for subsequent releases is that more features will be migrated, more things will be cached, and the performance gains will get better and better. The performance gains strongly depend on your app usage, the JDK version you are using, and how good is the training you are doing.

In the next post we will explain how to use the new AOT capabilities that are available in both JDK25. We will also present test results which show that very significant progress has already been made and is set to continue on capabilities already present in JDK 26 and on.

Are online events the new normal?

María Arias de Reyna — Wed, 28 Oct 2020 14:20:00 +0000

Some of you may know I am going to co-chair the next FOSS4G. ( Come Hell or High Water, but we are going to have a FOSS4G next year! ) I have also participated on the organization of the last ApacheCON and some other minor online events. I have also spoken on many online events by now.

And, let me tell you, I am not as optimistic as those people. I really hope this post ages badly and in the following years we get better options for online events.

But as of today, I don’t feel we are anywhere close to replace face to face events with online ones. Delivering the talks as streaming is something good but we will be losing most of what makes a conference an amazing experience.

Let me tell you why.

Online Events Drawbacks

Online events allow people from all over the world to attend without having to travel. People with hard conciliation and people that can’t afford or are not able to travel will be on your event. It’s true, you will get attendees you wouldn’t have if it was a face to face event. And that’s good!

But that’s where the advantages of an online event end. And where a lot of new issues are created.

Timezones

Have you ever tried to find a good time slot for a simple one hour meeting between an Australian and someone living in Los Angeles? Exactly.

Now imagine allocating at least six good hours for streaming and interactions and trying to have at least everybody awake, no matter if it is early or late. Spoiler: you can’t.

Of course you can always find some arbitrary schedule that fits your biggest group of potential attendees and force the rest of your attendees adapt to it. Just make them imagine they are traveling and live on a different timezone, waking up at 3am to watch your talks, having lunch instead of breakfast and sleeping during the day. Seriously: is your event worth it?

Do you remember those people that couldn’t travel to your face to face event but can attend your online event? A good percentage of them will not attend your online event if it doesn’t fit their timezone. It doesn’t matter if they have the means to do it.

Hacking timezones

Of course, there are patches for this. Like having a 24/7 event so at all times there’s something happening for the people that are awake at that time. Which, in summary, just means having like separated events that overlap a bit between regions of the world. You will end up interacting mostly with people on your time zone region.

Some events are replaying their talks at different time zones so everyone has the opportunity to attend all sessions. But what’s the fun of watching some past talk, when even the speaker is no longer available for questions? I can watch it next month and it will be the same.

Bandwidth

I just mentioned those people that couldn’t travel to your face to face event but can attend your online event. If only that was as truthful as it sounds.

Not everyone has a good internet connection at home. We can even say not everyone has an internet connection at hand to watch and participate on your event. Thinking otherwise just shows your privilege and how you forget not everyone has access to a good and stable bandwidth. Specially at home.

For some people it is easier to travel to your face to face event than to get a good bandwidth to watch the streamed talks.

So this group of people that wouldn’t travel to your event but would attend your online event just keep shrinking. Your real potential attendees are those in the right time zone and the right technological requirements.

Shadow Audience on Online Events

This one is for speakers. There’s no way your talk will be the same if you can’t see, hear and feel the audience as in face to face. Online events, no matter if the audience has their cameras on, are isolating. It is never the same.

Not having feedback on how well your talk is being received (or even worse: seeing a lot of cameras of distracted attendees doing something else) is a huge handicap that even the most experienced speaker will suffer. Not knowing if you should speed up or slow down to adapt to your audience is weird. Not knowing if your audience is laughing at your jokes or thinking you are a weirdo.

And probably your speakers are not familiar with your platform, which means they will be extra nervous of messing up. If the mic fails on a room full of people, you notice immediately and you can even just talk louder while it gets fixed. If the mic fails on an online event, you may not even notice until several minutes have already passed.

All these issues lead to talks not as good as those made face to face.

Disengagement

Let’s be fair: attendees will not be physically disconnected from their daily routines as they are when traveling to your event. Most of them will keep going to work, passing time with their families and even skipping some talks to do house work. These changes of context means losing attention.

Your event is just the side dish of their day to day, an extra appendix. They will never be as engaged as if they had to travel to a venue and be there physically.

Language Barrier on Online Events

I know, I know what you are thinking. No, María, this problem is the same, no matter if you are face to face or online. Let me guess: you are an English native speaker.

Even when having reliable broadband and enjoying high quality smooth 60fps video, understanding a foreign speaker over video is harder than in person. Maybe because the audience is shadowed and the speaker has no feedback on how well it is being received. Or maybe it is just because we speak differently face to face than online. Maybe we are missing corporal language. But it happens.

This could be fixed with subtitles on most cases. But, what kind of subtitles? The ones that run on the fly and so frequently confuse technical terms making the subtitle confusing? Or the ones that are attached to a pre-recorded video so the speaker is not really there?

No random meetings

As you don’t have to move from one room to the next, sit next to someone on a room or even mingle during the coffee breaks, you just lose all those opportunities to meet both friends and strangers.

Your event will be missing a space where attendees can meet more or less randomly. Some events are matching random attendees on private rooms or have general room halls for random chatting. And that’s a good idea, but still, it doesn’t replace introducing yourself to someone specific you feel is a good match when you see that person talking to someone you know or having a break and being open to engage in conversation.

Do you want to have an Ice Breaker or a Gala Dinner? Maybe you can try Mozilla hub for that. Too over complicated? High hardware requirements? But what other social platforms could be there that go beyond a chat and are not a simple video conference? How can we mimic this walking over the venue and saying hi to old friends or asking someone about their shirt drawing?

Financial Side

Contrary to popular belief, if you really want to have an online event that can compete with a face to face event, the cost will not be cheap. The proper software stack with the proper bandwidth can be as costly as the venue. And whatever you may be saving on catering you will spend in making the event more social and engaging.

It’s true that a basic online event can be done very cheaply, as I demonstrate on the next section. But still, it will be a cheap event and will not patch many of the social drawbacks exposed.

If you want to make the conference online, you have to work towards more lines of economic viability than in traditional face to face events. Because there are many things you can’t offer now (being the merchandise placement the most obvious one).

Sponsorship of Online Events

Obviously you will try to keep sponsors on board. But it would be insane to think sponsors will be willing to pay the same prices as in traditional events if you don’t offer anything above and beyond.

If your conference has some kind of sponsorship booth area, you need some kind of replacement. How do you plan to do that? And how are you going to make attendees go through it? Now you don’t have halls where the booths are showing fancy stuff.

If you host some kind of Business to Business slot, are you just going to run it as a normal online video session? How are you going to help them interact?

Tickets

Most face to face events reconverted to online events are “in panic” offering free tickets, which will make it difficult for any online event to sell tickets at a reasonable price in the near future.

To make sure people would want to pay for your specific event, you must prepare some extras besides the streaming. You have to offer some kind of exclusive content to paid attendees besides the basic chats on the streamings to make sure the ticket price is worth it.

Maybe promote more panels where only paid users can participate and ask questions? Adding prizes or badges to users that participate more or attend more sessions?

Some events are offering open price donation tickets. Which means, you can have the ticket for the price you deem it worth. I have seen (from the inside) a number of events doing this. I won’t share actual numbers but trust me: don’t count with this money.

Goodies

Have you thought of an online shop to sell goodies branded as the conference? Difficult to estimate if this will work if you haven’t sell goodies before, but tech conference attendees are well known for collecting branded shirts. This is worth a try.

Dare Donations

This was an idea that popped out watching the Games Done Quickevents. They keep people engaged and donating money through a whole week. They propose “dares” and people donate to vote what to do. You have to find something that make attendees engage and control somehow the type of content they are going to see.

For example: If between 9:00 and 10:00 we get a minimum amount in donations, then some speaker will run a live demo on their presentation instead of a video. Or vote with donations what question to ask on a panel. Maybe even choose between two different talks.

This works awesomely well on the GDC but the GDC is a fun event with no consequence and that’s not the tone with most tech conferences. I have no way to estimate if this will work on our case. It may work if you choose the right “dares” and speakers are willing to collaborate.

Probably easier on FOSS conferences, where the camaraderie is a common denominator. Weirder in other types of conferences, specially academic ones.

Software Stack of Online Events

There are many valid software stacks to use for your online events. Here is a summary of what I have experimented with and what I am comfortable with.

Let’s start with a basic stack that covers minimum functionality for a cheap price and then proceed to more wholesome solutions.

The Basic Stack

This is the basic stack I have found that covers the minimum needed to offer a proper online conference: talk streaming and access to a VIP chat. The price would be ridiculously cheap if you use one of the popular free streamings like Twitch or YouTube.

OBS Studio

OBS Studio is an old friend of streamers. And also FOSS. No matter what streaming platform you are going to use (something free or some custom server), it works. You can have combined screens and cams and different audio sources to get a beautifully orchestrated output.

If you follow gamer streamers, you will probably be familiar with OBS already.

If OBS Studio is too complex to use for you, your moderators or even your speakers, you can always try StreamYard. It offers a similar functionality on a web browser friendly interface. It will allow you to easily stream to popular free platforms too. Personally I am very satisfied with this tool, even if it is not FOSS. It is really easy to use and the hardware and knowledge requirements are low.

Mattermost

To cover the social side, Mattermost is my preferred option. It is a Slack-like messaging platform where you can offer special channels to your attendees according to their ticket (free or paid). There, you can have access to all social interactions; like asking the speakers, meeting other attendees or discussing on common rooms.

Website

Although this stack covers all the minimal requirements for an online conference, it is messy and with decoupled parts. Your attendees may feel lost.

Attendees will have two windows or tabs in the browser: Mattermost and the streaming. The links to each streaming talk may be on some schedule in some webpage. It will be worth adding some developing time to create a website that contains everything on an usable format and gives some sense of being a single component.

Offline Talks for Online Events

If you are afraid your software stack may fail at the worst moment, you can ask your speakers to send their recorded presentations before the online event. You can even ask them for optional subtitles to overcome any language barrier.

Asking for recordings in advance gives you time to test if the video is right and schedule the release at the proper time and date. This reduces a lot the possibility of real time failures. Also, this way you make sure all videos have the proper duration, making the schedule more stable.

This gives the speakers also the opportunity to edit their videos on a fancy friendly way, adding special effects or anything that may be too risky to run on real time.

The speakers can also be asked to be at that proper time and date on the chat to interact with the attendees so the Q&A can run as usual.

But the event will probably look less dynamic, with all these pre-recorded talks. No cross-referencing talks you just watched, no possible change mid talk because someone made a good point.

Promising Software Stacks

If you don’t want to use the free streaming options and/or you are looking for a more holistic solution, there are some platforms and software stacks you can check. Take into account that these options require you to have the proper bandwidth, which means, they are going to be more expensive than the previously described minimum viable plan.

So the first thing you have to ask yourself before jumping into any of these platforms is: is it worth the risk of using our own/rented streaming servers instead of something like YouTube or Twitch?

The most attractive (to me) alternatives right now are the following.

BigBlueButton

BBB is a FOSS Conferencing System for online learning. Not designed as a conference software, it provides the users with class-like rooms and a chat per room. As a tool for teachers I felt it was very complete. As a tool for an online event, I felt things missing. It felt like many disconnected talks, not like a full schedule.

Venueless

From the creators of Pretix and Pretalx, Venueless aspires to be the FOSS option for conferences. It is built on top of Big Blue Button, offering a wrapper that should make the experience more “conference-like”. I have to confess I haven’t tried it yet, but seeing how Pretix and Pretalx work, I’m confident this is going to be a big one. If you are considering using BBB, you should take a look at this one. If only because it provides features on top of it.

Both options have the huge advantage of being FOSS, which means, if you don’t like or need something in particular, you can dedicate your own developers into contributing for it. Even if you use a third party hosting, with proper care your contributions will make it to the main release so any third party hosting will offer them for you.

Hopin

Hopin.to was used on ApacheCON. It is not FOSS, which means you are completely dependent on what the company behind it wants to implement. For me, that’s a big red flag, specially on online events, which is something the software stacks are not yet mature enough. You cannot be confident yet that a restricted licensed software will be mature enough to provide you with everything you need.

On the social side, Hopin offered fancy features like matching you with random attendees, mimicking what a coffee break would be, or offering specific booth rooms so you can talk with sponsors.

Truth is, I am usually very social on face to face events and talk with random people and visit the booths. But nothing was calling me to use these features on the online version of this conference. It’s not as if you see someone you want to talk to in the coffee break so you just approach them. It looks forced to me. The risk of matching a complete stranger with nothing in common and having an uncomfortable conversation was high.

Online Events Experiences

I’m sure all of you have some experiences with online events by now. Let me share some insights I have experienced and why I still think online events can’t replace face to face ones.

EsLibre experience

The EsLibre used Big Blue Button as the main conference platform, with RocketChat as the sidechat and MozillaHub for the Gala Dinner and social “after beers”. The experience was pretty good… except everything was disconnected, as we were using three different components completely decoupled.

And still, not the same as a face to face.

ApacheCON experience

ApacheCON used Hopin. It was in general a good experience, well organized, and we had more attendees than ever. But that may be misleading: most of the almost six thousand registered attendees logged in at some point in the event, but you rarely saw more than a thousand connected at the same time.

We used the “three timezone region” approach, which in the end led us to have like three different groups of attendees that didn’t mingle among each other.

Conclusion

Online Events can’t match Social Face to Face Events

At least, not for me, not with the technology and the social capabilities we have right now.

I really really hope this post ages badly. Because there’s a lot of people that can’t travel to online events and they are missing all the awesomeness of a full event experience.

And, truth be told, having everyone traveling several times per year to different conferences is not ecological, not sustainable in the long term.

The post Are online events the new normal? appeared first on my personal blo.

What’s all this integration agitation, anyway?

María Arias de Reyna — Tue, 06 Oct 2020 18:05:00 +0000

You may have heard any or all of these keywords before: middleware, integration, orchestration. And you may be wondering why and when to use them. Take a walk with me to understand when and how integration frameworks are useful.

Imagine you are in charge of solving a new need of your company. There is no complete software stack for what you need. You will have to involve your team to create something new. Even if you reuse some components, you have to make them interact and talk to each other.

You are an experienced software engineer and have solved previously many of the requirements with some components you are already familiar with. But now you have to orchestrate all these components together and make them work like a clock. Now you need a proper integration. You want all of them to cooperate smoothly in your architecture.

The first thing any good developer thinks about is building a custom software that acts as the glue between all these components. Maybe adding some fancy extra functionality. And, (why not?) as we are at the beginning of a new exciting project, probably we want to try all these new technologies you have been reading and hearing about. Whatever the fad buzzword is now, you are willing to try it.

Although this may be appealing, your inner experienced engineer tells you to stop. There’s something you also read about, these integration frameworks. Could they be useful here?

The Integration Paradigm

As much as we would like to start a new clean project from scratch and throw all our ingeniousness into it, we shouldn’t reinvent the wheel. Let’s take a look at what is this middleware or integration software.

Middleware, or integration software, can help us orchestrate and automate the interaction between different applications, APIs, third party services or any other software piece we may have to connect.

A proper integration tool should provide us with the following features: transformation, integration patterns and connectors to existing protocols and components.

Transformations

When we connect different components of an architecture, they rarely speak the same languages or, on this case, data formats. Some components will output an xml that has to be fed to the following component on a json form. Maybe we even need to add or remove some attributes on that json data.

We need some way to easily transform the data traveling from one component to the following so it fits properly.

If we want to do this with our own script, there are many libraries that can help us doing this like Jackson or the built-in xml libraries on Python . We even have the XSLT language to transform XML. But to use any of these properly, we would have to learn first how to use them. And any code we generate will have to be maintained and upgraded properly.

An integration framework allows us to define what is the mapping between the output of one component and the input of the following so we can forget about the explicit implementation. The less code we have to maintain, the better.

Enterprise Integration Patterns

Not all workflows in the architecture will be lineal. Some of the steps will require broadcasting, some of them will require conditional flowing. Some will require waiting the output of different components to conflate the data. These action patterns are something that have been studied for a long time. And as with software development patterns, you can classify them and study them to create better integrations.

You can find all of these patterns prettily explained in the classic Enterprise Integration Patterns book.

Connectors

All of the above is useless if we can’t connect to (and from) the specific component we need.

Our ideal integration framework should offer support for common protocols like ftp, http, jdbc,… Also it should offer support to connect to common components like a mail server, messaging services, atom,… We could claim even that no integration tool would be good if it doesn’t also support specific well known services like being able to send a message through a Telegram bot or store information on Elastic Search.

Being able to seamlessly connect from one component to the next without having to worry about the specifics of their interfaces is what distinguishes an average integration tool from a good integration tool.

Apache Camel

Let’s talk about something less abstract. At this point you may be wondering where you can find a good integration framework.

Apache Camel is not only one of the most active projects inside the Apache Software Foundation, it is also the lightest and most complete integration framework available. And on top of it, it is also Free and Open Source Software!

Camel is already an old actor on the integration world. It has support for hundreds of components, protocols and formats. Some of these protocols come very handy allowing the user, for example, to connect to any REST API that they need.

Camel uses its own DSL, a simplified language to define easily the workflows step by step.

Camel-K

Camel is also available in Knative. This means, we can use it on a serverless environment, making sure the orchestration between services runs and escalates properly.

Camel K Orchestration Example

This example demonstrates how to orchestrate integrations using Camel-K and Kafka as a messaging service. We are going to implement two integrations that interact through a database to simulate how cat adoptions work.

The full example can be found on Github.

Two integration workflows that simulate how cat adoptions work

One integration will store cats coming from Kafka to the database waiting for a person to adopt them. The second integration will receive people interested in adopting and will match cats with them.

Cat Input from Kafka to Database

First we are going to implement the storage of cat input messages to the database.

As you can see, the Camel DSL is very intuitive: this integration listens to the proper Kafka broker and for every message that arrives, it unmarshalls the json to extract the data and pushes it to the database. The Cat class is just a simple bean with getters and setters for the attributes.

// camel-k: language=java

import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.model.dataformat.JsonLibrary;
import model.Cat;

public class CatInput extends RouteBuilder {
  @override
  public void configure() throws Exception {

    //Listen to kafka cat broker
    from("kafka:cat?brokers=my-cluster-kafka-bootstrap:9092")
    .log("Message received from Kafka : ${body}")
    .unmarshal().json(JsonLibrary.Gson, Cat.class)
  
    //Store it on the database with a null person
    .setBody().simple("INSERT INTO cat (name, image) VALUES ('${body.name}', '${body.image}')")
    .to("jdbc:postgresBean?")
  
    //Write some log to know it finishes properly
    .log("Cat stored.");}
  }
}

Person Input from Kafka to Adopt

Now we are going to implement the reception of people wanting to adopt a cat.

This integration is a bit more complex, as we are going to introduce a conditional choice: if there is a cat available on the database, it will be assigned to the person. If there is no cat (otherwise), a message will be returned saying no cat is available.

// camel-k: language=java

import org.apache.camel.builder.RouteBuilder;

public class PersonInput extends RouteBuilder {
  @override
  public void configure() throws Exception {
    //Listen to kafka person broker
    from("kafka:person?brokers=my-cluster-kafka-bootstrap:9092")
    .log("Message received from Kafka : ${body}")
    .log("${body} wants to adopt a cat")
    
    //Store the name of the person
    .setProperty("person", simple("${body}"))
    
    //Search for a lonely cat
    .log("...looking for available cats...")
    .setBody().simple("SELECT id, name, image FROM cat WHERE person is NULL LIMIT 1;")
    .to("jdbc:postgresBean?")
    
    .choice()
      .when(header("CamelJdbcRowCount").isGreaterThanOrEqualTo(1))
        .setProperty("catname", simple("${body[0][name]}"))
        .setProperty("catimage", simple("${body[0][image]}"))
        .setProperty("catid", simple("${body[0][id]}"))
        .log("Cat found called ${exchangeProperty.catname} with ID ${exchangeProperty.catid}")
        //There's a cat available, adopt it!
        .setBody().simple("UPDATE cat SET person='${exchangeProperty.person}' WHERE id=${exchangeProperty.catid}")
        .to("jdbc:postgresBean?")
  
        //Write some log to know it finishes properly
        .setBody().simple("Congratulations! ${exchangeProperty.catname} adopted ${exchangeProperty.person}. See how happy is on ${exchangeProperty.catimage}.")
        .to("log:info")
      .otherwise()
        //Write some log to know it finishes properly
        .setBody().simple("We are sorry, there's no cat looking for a family at this moment.")
        .to("log:info")
    .end();
  }
}

Feeding data automatically

As an extra step on this exercise, we are going to implement a final job that sends random new cat data to the Kafka “cat” topic with a timer.

The complexity on this class is not the Camel side, but the random generator of cat names.

// camel-k: language=java dependency=camel:gson

import java.util.HashMap;
import java.util.Map;
import java.util.Random;

import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.model.dataformat.JsonLibrary;

public class AutoCat extends RouteBuilder {
  @override
  public void configure() throws Exception {

    // Preparing properties to build a GeoJSON Feature
    Processor processor = new Processor() {

      String[] title = new String[] { "", "Lady", "Princess", "Mighty", "Your Highness", "Little", "Purry", "Empress", "Doctor", "Professor" };
      String[] firstname = new String[] { "Dewey", "Butter", "Merlin", "Epiphany", "Blasfemy", "Metaphor", "Fuzzy",
          "Whity", "Astro", "Salty", "Smol", "Whiskers", "Scully" };
      String[] lastname = new String[] { "", "Luna", "Wild", "Dragonis", "Firefly", "Puff", "Purrcy", "Priss",
          "Catsie" };

      Random r = new Random();

      @override
      public void process(Exchange exchange) throws Exception {
        Map<String, String> map = new HashMap<String, String>();
        map.put("image", exchange.getProperty("catimage").toString());

        StringBuilder name = new StringBuilder();
        name.append(title[r.nextInt(title.length)]);
        name.append(" ");
        name.append(firstname[r.nextInt(firstname.length)]);
        name.append(" ");
        name.append(lastname[r.nextInt(lastname.length)]);

        exchange.setProperty("catname", name.toString());
        map.put("name", name.toString().trim());

        exchange.getMessage().setBody(map);

      }

    };

    // Listen to kafka cat broker
    from("timer:java?period=10s")
      
      // Take a random image
      .to("https://api.thecatapi.com/v1/images/search")
      .unmarshal().json(JsonLibrary.Gson)
      .log("A new cat arrived today ${body[0][url]}")
      .setProperty("catimage", simple("${body[0][url]}"))

      // name cat and prepare json
      .process(processor)
      .log("${body}")
      .marshal().json(JsonLibrary.Gson)
      .log("We named them ${exchangeProperty.catname}")

      // Send it to Kafka cat broker
      .to("kafka:cat?brokers=my-cluster-kafka-bootstrap:9092")

      // Write some log to know it finishes properly
      .log("Cat is looking for a family.");

  }
}

Now you are ready to implement your own orchestrations with Kafka and Camel K.

The post What’s all this integration agitation, anyway? appeared first on Délawen's blog written by María Arias de Reyna Domínguez.

From Cat to Hat

María Arias de Reyna — Fri, 19 Jul 2019 10:54:39 +0000

On June I joined Red Hat as a Senior Software Engineer. I always said that I preferred to work on a small company before a big company, because on a big company you can’t be anything more than a number. That you can’t really grow professionally if you are such a small piece on a … Continue reading "From Cat to Hat"

The post From Cat to Hat appeared first on Délawen written by María Arias de Reyna Domínguez.

I want to fix the diversity on my event, help me!

María Arias de Reyna — Sun, 07 Jul 2019 19:34:16 +0000

If someone linked you this post is probable you are organizing an event where diversity and inclusivity is an issue and they want to help you fix that. If you want, you can jump to the subsection that better adjust to your case. Remember: diversity is not a TL;DR, you probably need to read the … Continue reading "I want to fix the diversity on my event, help me!"

The post I want to fix the diversity on my event, help me! appeared first on Délawen written by María Arias de Reyna Domínguez.

How can I get a diverse and inclusive team?

María Arias de Reyna — Wed, 05 Jun 2019 17:25:47 +0000

TL;DR: If you are really interested on improving the inclusivity and diversity on your team, you need more than a TL;DR

The post How can I get a diverse and inclusive team? appeared first on Délawen written by María Arias de Reyna Domínguez.

Why do we need diversity on our teams?

María Arias de Reyna — Mon, 07 May 2018 21:09:45 +0000

Let’s overlook the statistical justice of having a diverse team. Let’s overlook the social justice of working on a team with high diversity. Go directly to why you, someone interested in having business at the end of the year, are also interested in having a diverse team… Continue reading "Why do we need diversity on our teams?"

The post Why do we need diversity on our teams? appeared first on Délawen written by María Arias de Reyna Domínguez.