Payara Server in Production - Quick Tip

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!