Technical Blog Post
Deploying the RMI registry in a Maximo Clustered Environment, part 1
Many of you are familiar with the recommendation to deploy the RMI registry file, rmireg.war and have probably seen these two great tech notes below:
However, I understand a lot of you may be wondering how many, where and why for a clustered environment?
This blog will look at elaborating on the fundamental concepts explored in the above tech notes and be geared more specifically to how we can achieve the deployment of the RMI in a WebSphere clustered environment.
This is the first of a three part blog that covers the steps from start to finish.
Firstly, let's clarify some common questions I have come across from customers trying to set up their RMI
1. Why do we need to deploy a separate RMI registry file for a clustered environment?
Simply, for availability. It creates the registry independent of any other Maximo JVMs in the cluster and continues to run even if another server in the cluster fails.
If a JVM is shut down or recycled, the RMI communication is not lost.
NOTE: If the mxe.allowLocalObjects property is set to 1 in your environment, then the user interface does not use the RMI registry. The RMI registry is only needed if the RMI client program is used.
2. How many RMIreg.war files do we need to build and where do they need to be deployed?
You need to have a RMI registry file, rmireg.war deployed in a separate JVM for each physical WebSphere server where your Maximo Clusters are running.
3. Which properties file is used to edit and build the RMI registry port values? I have a few properties file in my clustered environment, one for MIF, Cron and UI.
Follow on Part 2, Building and deploying RMI file for a clustered environment for the answer to this question...