Showing results for 
Show  only  | Search instead for 
Did you mean: 

Deploying multiple IdentityIQ instances

Deploying multiple IdentityIQ instances

The steps to deploy each, single IIQ instance depend upon the specific app server env. Each IIQ instance runs inside a separate JVM from the application server(s) context.


When repeating these steps for multiple IIQ instances, apply the app server's system engineering and performance sizing rules/guidelines to deploy each IIQ instance with sufficient resources.


In most environments, multiple IIQ instances (of the same version) share the same underlying repository. Every IIQ instance uses a "" startup file with the repository connection info. The actual repository must provide sufficient throughput/resources to handle all requests.


The file also contains two properties, "taskSchedulerHosts" and "requestSchedulerHosts", that contain hostnames (CSV with values formatted as from InetAddress.getHostName method). When set, then task and request schedulers only start on the (listed) hostnames:





The task scheduler manages threads for scheduled tasks. The request scheduler processes emails, provisioning, and other events. Neither of these settings impact the UI requests from

users/browsers (via HTTP session).


While IIQ's hostname defaults to the string returned by JDK's "InetAddress.getLocalHost().getHostName()" method, the JVM system property "iiq.hostname" can be used to override the value. This allows running multiple instances on the same "box" to take advantage of multiple cores/cpus. The configured string then appears as the hostname in the result from "about" (console or debug UI) along with other scheduler info.


As a best practice, assign unique names among all IIQ instances. For example, WebSphere's admin tool offers an UI for instance-specific generic JVM arguments (such as "-Diiq.hostname=foo1"):


Lastly, in same "box" environments, IIQ instances also share the same filesystem(s). This impacts the IIQ logging feature when IIQ instances even share the "" file. To avoid concurrent logging to the same file, either direct messages to the instance's stdout (then cfg app server to save instance's stdout to unique file) or start each instance separately (then modify "" output file).

Labels (1)

Have things always been like this, or is there a minimum IIQ version to which this applies?

The only thing version specific I see in this post is the ability to control which instances run the task processor and request processor.  That capability was introduced in IdentityIQ 3.0, for all practical purposes for most, it has always been like this.

Cool, I know what's coming our way, then. Thx.


Just wanted to confirm that these steps remain the same for the recent versions as well? We are installing 7.0p2 and would like to know if there is anything additional that needs to be done for clustered deployment. The file does not have those two environment properties, i believe i just need to add those two and specify the hostnames?


Please have a look at this document: Partitioning Best Practices

There are several benefits from using the ServiceDefinition to control multiple instances.

Kind regards,


Version history
Revision #:
2 of 2
Last update:
‎Aug 01, 2023 07:52 PM
Updated by: