Another quarter, another release! After an eventful 2016, November brings with it the final release of the year for Payara Server. This year, we've seen new services like Request Tracing and Health Check added, as well as the Slow SQL logger and SQL Trace Listeners. Revisiting the version of the documentation from 1 year ago and comparing the amount we have added since then is, frankly, astonishing!

Despite a bumper year for both new features and bug fixes, work continues apace! Below is a short summary of some of the things to look out for in a release that caps an incredible 12 months.

Any project, large or small, would ultimately like to follow industry best practices, such as continuous deployment.  In order to support this, applications must be deployed early and often.  This, in turn, triggers downtime and the users get affected by it because they could be logged out of the website, or worse, their work gets lost because the application's intermediate state is not saved - never mind the actual downtime during the application deployment process.

Rolling upgrades solve this problem in an efficient way!

Payara Micro is packed with most of the features and APIs that come with Payara Server Full Profile even though it doesn't entirely support whole Jakarta EE Full Profile. As an example, Payara Micro supports persistent EJB Timers, which are only required by the Jakarta EE Full Profile and not by the Web Profile. In Payara Micro, it's possible to use persistent EJB Timers, which are stored across your micro instances inside the distributed data grid as long as at least one instance in the data grid is up and running.

As part of the new features introduced with the release of Payara Server 162, you can now form a cluster of Payara Server instances using the concept of Hazelcast “Lite Nodes”. This can help you create more flexible cluster topologies.

Take a look at this quick demo to see some of Payara Micro's  dynamic clustering capabilities. I'm running the demo without any extra tools, just Payara Micro itself. To show how Payara Micro dynamically rebalances the cluster, I used JCache and Payara Micro's --autoBindHttp feature.

Application server clustering provides a means to make application infrastructure more robust and perform better. However, it is often very inflexible and even a small change in the cluster topology can involve serious maintenance costs. Payara Server supports a new way of clustering based on Hazelcast, which brings much more flexibility, decreases maintenance costs and adds the benefit of JCache support out of the box.

GlassFish has traditionally used Project Shoal to power its clusters. Since Shoal is no longer actively maintained, Payara Server intends to replace Shoal with Hazelcast, which has the added benefit of being JCache compliant.

In the first part of this 'Introduction to Payara Scales' blog, I will give you an overview of the architecture for a Payara Scales cluster and a load balancer upfront, using Amazon CloudFormation and Amazon EC2.

One of the lesser known features and key benefits of Payara Server is that it provides huge flexibility when architecting topologies for High Availability and Scalability. Utilising the embedded Hazelcast Data Grid for web session and JCache clustering brings the potential of many different topologies for scale out.

Payara Micro is our new embedded distribution that was part of our latest release.