Posts from Lenny Primak

Photo of Lenny Primak

Find me on:

Setting Up Cache JPA Coordination with the Payara Platform using EclipseLink and JMS/Hazelcast

When it comes to clustering and distributed computing performance, some of the challenges you have to overcome involve cache invalidation and coordination. Fortunately, both Payara Server and Payara Micro come with EclipseLink, which supports cache coordination and invalidation out of the box. This blog will explain how to configure this feature for your Payara Data Grid.  We would also like to thank Sven Diedrichsen who is the community member that created the Hazelcast cache coordination.

Resolving Library Conflicts with Class Whitelisting

Many applications, especially complex legacy ones that are packaged with a large number of libraries, may contain libraries that are also shipped with Payara Server (like Google Guava or Jackson for example). These types of conflicts can be very hard to track down and solve. Starting from the  171 release of Payara Server, there is now another solution in the toolbox which can help with resolving these dependency conflicts.

Enhanced EJB Pool Controls in Payara Server

In prior releases of Payara Server, it was not possible to control the maximum number of concurrent Stateless EJB instances in Payara Server. It was, however, possible to control the number of pooled Stateless EJB instances, as well as concurrent MDB instances. These features were available in Oracle GlassFish Server 3.1 and earlier but not in the GlassFish Open Source editions (3.1.2.x and 4.x).

In the current release of Payara Server (171), it is now possible to limit concurrent Stateless EJB instances that are dispatched, allowing fine-grained control of resources, limiting surface area for DDOS attacks and making applications run more smoothly and efficiently.

 

Payara Server Rolling Upgrades

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!