Resolution
The steps to deploy each, single Access Governance Suite instance depend upon the specific app server env. Each Access Governance Suite instance runs inside a separate JVM from the application server(s) context.
When repeating these steps for multiple Access Governance Suite instances, apply the app server's system engineering and performance sizing rules/guidelines to deploy each Access Governance Suite instance with sufficient resources.
In most envs, multiple Access Governance Suite instances (of the same version) share the same underlying repository. Every Access Governance Suite 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 Access Governance Suite'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 Access Governance Suite instances. For example, WebSphere's admin tool offers an UI for instance-specific generic JVM arguments (such as "-Diiq.hostname=foo1"):
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/utrb_classload_viewer.html
Lastly, in same "box" envs,Access Governance Suite instances also share the same filesystem(s). This impacts the Access Governance Suite logging feature when Access Governance Suite instances even share the "log4j.properties" file. To avoid concurrent logging to the same file, either direct msgs 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).