Encryption of the data stored within the data grid of Hazelcast (the technology underpinning our deployment groups and clustering in Payara Platform 5) has until now required a Hazelcast Enterprise subscription (see Payara Scales). While this remains an option for those who would like the additional features it provides (such as WAN replication), we’ve begun introducing this particular feature into Payara Server itself to provide it to you without needing an additional subscription.

In Payara Server 5 we will be introducing some major changes to the way clustering is working by creating the Domain Data Grid (see documentation for more info). The Domain Data Grid will be easier to use, more scalable, more flexible and ideally suited for cloud environments and cloud-native architectures. All Payara Server instances will join a single domain-wide data grid for sharing of in-memory data like web sessions, JCache, SSO and Stateful EJBs. 

Taking our introductory series onwards, this blog will look at how you set up a simple Payara Server cluster on Windows using the native remote control protocol, DCOM. We will set up two instances on Windows 10, controlled by a third Domain Administration Server (DAS) instance on Windows 7 via DCOM, and cluster them together using Hazelcast. Finally, we will deploy our trusty clusterjsp application to demonstrate how the data is being shared across our instances.

In order to make a cluster of servers appear as one server, you need to introduce a load balancer. A load balancer will accept a request, and redirect it to one of the members of the cluster depending on a given configuration. A web server such as NGINX or Apache can act as this load balancer as well as a reverse proxy, which allows the web server to load balance requests across the cluster, act as a termination point for SSL connections to reduce strain on the cluster, as well as cache server content for quicker access. In this blog, we will set up NGINX as a reverse proxy and secure it using SSL.

Continuing our introductory blog series, this blog will demonstrate how to add load balancing capability to Apache Web Server and forward to our simple Payara Server cluster. 

A load balancer can redirect requests to multiple instances, primarily for the purpose of distributing incoming requests between cluster members based on pre-determined rules. This could be a simple "round-robin" algorithm, where the workload is distributed to each instance in turn, or a weighted algorithm where requests are delivered based on a pre-determined weight for each cluster member.

Continuando con nuestra serie de blogs de introducción, este blog va a demostrar como añadir la capacidades de balanceo de carga a un Servidor Web Apache y asi re-enviar las peticiones HTTP a nuestro cluster de Payara Server.

Kick-starting yet another year, we are pleased to announce our largest release yet - Payara Server 4.1.1.171. Building on a year's worth of updates and improvements, in this release, you can find 18 brand new features and over 60 new fixes and enhancements for Payara Server & Payara Micro! Given the size of the additions, look out for detailed blogs in the near future. For now, check out below for a summary of the changes in 171 release, and have a look at the full release notes.

In our continuing series on alternatives for commercial Oracle GlassFish features , in this article we are looking at Hazelcast - a replacement for Oracle's Coherence ActiveCache.

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.