Identity Portal 1.6.2 cluster does not work when using MS SQL Server
search cancel

Identity Portal 1.6.2 cluster does not work when using MS SQL Server


Article ID: 4322


Updated On:


CA Identity Manager CA Identity Governance CA Identity Portal CA Identity Suite


When using MSSQL database server - the application clustering does not function


Identity Portal 1.6.2Identity Manager Suite 12.6 SP8


Identity Portal 1.6.2 introduces a new clustering configuration where every node registers itself into a JGROUPSPING table in the database during application startup.

When 2 or more nodes are configured to use the same database schema, they are automatically being made cluster members.

This mechanism will work seamlessly when using Oracle as the database.


When using MS SQL as a database, a manual change to the Application Server XML configuration file is required.


If you are using MS SQL as the database for Identity Portal 1.6.2, you must make the following configuration change on all nodes:


a. Edit the application server configuration file (e.g. if using JBoss/Wildfly – this is standalone.xml)

b. Locate the following directives:

c. Notice that the default values are pointing to the ORACLE template files.

d. Replace the values ("sigma-portal-jgroups-unicast-oracle.xml" and "sigma-hibernate-jgroups-unicast-oracle.xml”) with their MS SQL template files (see example below).
Note: you should make sure that every replaced value points to a valid file in the file-system.

here is a working example from a Linux machine:

<property name="sigma.portal.cache.infinispan.jgroups_cfg" value="/opt/CA/IdentityPortal/IdentityPortal/3rd-party-config-files/jgroups-cluster/sigma-portal-jgroups-unicast-mssql.xml"/>

<property name="sigma.hibernate.cache.infinispan.jgroups_cfg" value="/opt/CA/IdentityPortal/IdentityPortal/3rd-party-config-files/jgroups-cluster/sigma-hibernate-jgroups-unicast-mssql.xml"/>

e. Restart the application server


Validation procedure for an Identity Portal cluster:


a. Make sure all cluster nodes are started with their connector started (this example will assume there are 2 nodes)
          Note: you must follow the documentation to synchronize the nodes secret key, otherwise the connector will fail to start on more than 1

                    node simultaneously. See the following section from the installation guide:

b. Login to the admin UI of both nodes (in 2 separate browser windows/tabs)

c. Open any defined form in both tabs (each form will open on a different Admin UI – hosted on a different cluster node)

d. On node 1 - change or add a property on this form and save

e. On node 2 - press "F5" to refresh the browser and notice the property was changed.

f. Repeat the test in reverse (change/add a property on node 2 and check it was refreshed on node 1)