Payara Server in Production – Quick Tip

Uncategorized

TIP: Don’t deploy any apps to the DAS in production!

Why?

As is the case with all my stories, this one began at a customer site. They had an old app they were migrating from GlassFish 3.1.2 to the latest version of Payara Blue. They’d called me in because they wanted to benchmark performance of the new version of Payara Blue on AIX against their existing GlassFish 3.1.2, also on AIX, as well as against a recent version of JBoss (I’m unsure of the version, though I know it was deployed on Windows).

 

While they had been trying to deploy their application they had noticed an odd problem whereby the deployment appeared to not succeed and, upon restarting the server, they would find that the admin console would not load properly after logging in, leading them to conclude the domain had been corrupted.

 

Since their evidence of the app not deploying was in the admin console, this lead to a lot of frustration and extra time wasted!

 

Not long after I arrived, I suggested they create a new, local, standalone server and deploy to that instead. This would mean that any changes would happen to a separate configuration which would not interfere with the DAS at all and not require any downtime for the admin console.

 

The result was that we quickly discovered that there was no evidence of domain corruption at all, though there were plenty of packaged libraries which conflicted with each other as well as those in the server.

 

We never did definitively get to the bottom of the problems with deploying that app to the DAS (we had more pressing matters to attend to!) though we were pretty sure it was related to this particular app including RESTEasy. The admin console on the DAS is effectively a wrapper to the REST management interface and sends commands to the asadmin tool via REST. Since the admin console app gets loaded after all other deployed apps, it seems that these classes were conflicting with the ones in the DAS and causing problems from the first REST call – the log in.

 

Avoiding deploying apps to the DAS separates their lifecycle from your administration interface and, should anything go wrong with the deployment, it will not interfere with your steps to rollback the change to a previous, working version!

 

 

 {{cta(‘3e356116-b396-44e1-8477-c94637f914ce’)}}

 

 

Comments (0)

Post a comment

Your email address will not be published. Required fields are marked *

Payara needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Legal & Privacy Policy.

Related Posts

How to Run and Scale AI Java Applications in Production: An Overview for Developers with no Machine Learning Expertise 9 minutes
Jakarta EE

How to Run and Scale AI Java Applications in Production: An Overview for Developers with no Machine Learning Expertise

Organizations are increasingly interested in adopting artificial intelligence (AI) and generative AI (GenAI) to improve operations and offer next-generation […]

4 minutes
Uncategorized

Leading the Way: Payara Platform Community 7 Beta Now Fully Jakarta EE 11 Certified

We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]

What Is a Java Application Server? A Short Guide 6 minutes
Jakarta EE

What Is a Java Application Server? A Short Guide

Enterprise Java applications power global commerce, healthcare, government and countless other industries. These systems must be scalable, secure and […]