Submit Feedback
Legacy Knowledge Base
Published Sep. 10, 2025

Getting timeout exception during application restart in a cluster environment

Written By

Madhusudan Sharma

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

Issue

Getting the below error (TimeoutException) during application restart in a cluster environment:

Error: ERROR [localhost-startStop-1][ClusterSchedulerEngine:604] Unable to load memory 
clustered jobs from master in 10 seconds, you might need to increase value set to 
"clusterable.advice.call.master.timeout", will retry again
java.util.concurrent.TimeoutException

Environment

  • Liferay Portal 6.2

Resolution

  1. The issue might be due to network problems or, most likely, very high CPU usage.
  2. Might be one of the servers is exhausted and not answering in time for the communication between nodes.
  3. It could be due to a node being unable to reach the master node when asking for the memory-clustered jobs.
    Typically, in a clustered environment, in order for the node to be able to run the scheduled jobs in the event that the master node goes down, it needs to have the scheduled jobs in its memory beforehand. That way, if the master node went down unexpectedly, then the second node could become the new master node and pick up where it left off.

As a result, the above behavior might be possible due to some sort of connection issue between the nodes that prevents the request to retrieve the scheduled jobs from going through. If this is the case, the infrastructure or network team must be contacted.

Additional Information

Did this article resolve your issue ?
Legacy Knowledge Base
Did this article resolve your issue ?