Blogs

Usually there is a readiness-probe request to the Home page in order to check when the Portal has finished starting on each Application Server, in order to load balance the back-end node.

In versions prior to Liferay 7/DXP, when deploying all the applications within the Application Server, when it was correctly started, the readiness-probe to the Home page could be enough. In current versions of Liferay 7/DXP applications are deployed within the OSGi container, having a faster startup of the Application Server while the OSGi container continues to deploy applications to it. As soon as the Application Server is started, responses to those requests will start to be dispatched.

With this change, customers often ask what they need to do to check when their business solution (typically portlets) built on Liferay DXP is fully up and running.

For this reason I have developed the following module as a solution: business-core-status

How does it work?

Basically what the module does is expose an endpoint within the Portal when all the dependencies are available. But… What dependencies? The ones that really matter to us in our business, our Portlets and Services.

Technically, the module is an OSGi service that exposes a servlet on the /o/business-core-status/check endpoint.

This OSGi service will only be available when the ModuleServiceLifecycle interface dependencies for the PORTAL_INITIALIZED and PORTLETS_INITIALIZED events are available. These will be available once the phases corresponding to each event in DXP startup are completed.

Note that we also have a reference to a list of portlets. This list of portlets is the one that contains the important portlets for the business. This list is initially set to *, which requires configuration to indicate the business portlet name listing.

Use the cardinality.minimum property to indicate that we want the entire list of portlets to be injected, so that in the event that at least one of the list is not available, the endpoint will not be available either and our readiness-probe will not return a code 200 nor an expected html response for the node in question.

How do we configure it? 

To indicate which portlets we want to reference, we can create an OSGi configuration file for the Component, with the name com.liferay.business.core.status.BusinessCoreStatus.config

and deploy it to the directory ${liferay.home}/osgi/configs 

In my case, I refer to 2 Spring portlets that you can see in the same Workspace, so that the endpoint is available only when both portlets are available.

Conclusion

Deploying business-core-status in each application server, we will be able to monitor the endpoint offered by the servlet in order to determine when a node is ready to enter the balance or even as a Portal health-check, taking into account the applications that we estimate necessary to our solution.