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 "iiq.properties" startup file with the repository connection info. The actual repository must provide sufficient throughput/resources to handle all requests.
The iiq.properties 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:
environment.taskSchedulerHosts=SomeHost1,SomeHost2
environment.requestSchedulerHosts=SomeHost3,SomeHost4
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 "log4j.properties" 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 "log4j.properties" output file).
