Oracle will soon roll out Java 12 in March 2019 and new releases will drop once every six months thereafter. The goal is to make new releases more frequent for the Java ecosystem, with certain releases earmarked as long-term support (LTS). And by support, we mean the allocation of update releases for bug fixes and critical security patches. This latest version offers a list of new features such as Switch Expressions, Default CDS Archives, Shenandoah, Microbenchmark Suite, among others.

According to Oracle, Java is a fast, secure and reliable programming language and computing platform first released by Sun Microsystems in 1995. There are lots of applications and websites that will not work unless Java is installed, and more are created every day. From laptops to datacenters, game consoles to scientific supercomputers, cell phones to the Internet, Java is everywhere.

This is the story of a Java debugging journey that started with a question I couldn’t answer about Java stack traces. As a long time Java programmer, I am approached for help by developers who encounter unusual problems in the language.

Apache Tomcat is a server for Java-based web applications, developed by the Apache Software Foundation. The Tomcat project’s source was originally created by Sun Microsystems and donated to the foundation in 1999. Tomcat is one of the more popular server implementations for Java web applications and runs in a Java Virtual Machine (JVM).

In Part 1 of this series, we discussed some key Tomcat and JVM metrics that are exposed through Java Management Extensions (JMX). Now that you are familiar with metrics necessary for monitoring Tomcat, we can look at how to collect and query that data.

In Part 2 of this series, we showed you how to collect key Tomcat performance metrics and logs with open source tools. These tools are useful for quickly viewing health and performance data from Tomcat, but don’t provide much context for how those metrics and logs relate to other applications or systems within your infrastructure.

Apache ActiveMQ is message-oriented middleware (MOM), a category of software that sends messages between applications. Using standards-based, asynchronous communication, ActiveMQ allows loose coupling of the elements in an IT environment, which is often foundational to enterprise messaging and distributed applications.

In Part 1 of this series, we looked at how ActiveMQ works, and the key metrics you can monitor to ensure proper performance of your messaging infrastructure. In this post, we’ll show you some of the tools that you can use to collect ActiveMQ metrics. This includes tools that ship with ActiveMQ, and some other tools that make use of Java Management Extensions (JMX) to monitor ActiveMQ brokers and destinations.

As you operate and scale ActiveMQ, comprehensive monitoring will enable you to rapidly identify any bottlenecks and maintain the flow of data through your applications. Earlier in this series, we introduced some key ActiveMQ metrics to watch, and looked at some tools you can use to monitor ActiveMQ.