The runtime image of Payara Server consists of over 400 modules. Half of these do not come directly from the Payara codebase, but are various third-party APIs, their implementations and helper libraries. How do you choose the correct versions of your application's libraries so they are not in conflict with the ones in the server runtime?
One of the performance metrics that are frequently compared by developers are startup times. Payara Server is designed to be manageable at runtime, with a central management server (DAS - domain administration server) and multiple instances, and as such is not optimized for extremely fast startup time. Payara Micro on the other hand, is optimized to run predefined workloads with a stable configuration at runtime, and is therefore a better fit for for comparing start up time metrics.
In this blog, let's take a look at how you can configure Payara Micro for fast startup time by utilizing the class data sharing feature of Eclipse OpenJ9.
Payara Platform 5.194 was released recently, and just like the previous release, it is a certified Jakarta EE implementation. The request for certification can be seen on Jakarta EE platform project issue tracker.
We are very happy to report that we've successfully passed all of nearly 50,000 test suites of Jakarta EE 8 TCK, and Payara Server 5.193.1 is Jakarta EE 8 Full Profile compatible!
When running multiple instances of an application server, it is quite hard to see correlations between events. One of the best tools to enable that is the ELK stack - Elasticsearch for building fulltext index of the log entries, Logstash for managing the inflow the events, and Kibana as a user interface on top of that.
Solutions for Payara Server exist, that use better parseable log format which can be then processed by Logstash Filebeat in order to have these log entries processed by a remote Logstash server.
In our project, we chose a different path — we replaced all logging in the server and our applications with Logback, and make use of the
logback-logstash-appender to push the events directly to Logstash over a TCP socket. The appender uses LMAX disruptor internally to push the logs, so the processes does not block the application flow. This article will show you how to have this configured for your project as well.