It is possible to deploy several Rule Execution Server (RES) Console in the same cluster, however there are some administrative interactions from RES components to RES console that may not work due to the presence of more than one RES management stack within the same administrative scope.
When a RES component makes an attempt to interact with a RES Console management stack (through a JMX invocation) the following exception may occur if more than one RES Console is deployed within an administrative cell:
at ilog.rules.res.mbean.util.IlrSingleMBeanInvocationHandler.invoke(Unknown Source)
Note: a similar exception can be seen when no RES Console is found so the first thing to verify is that a RES Console is completely deployed and that it passes the diagnostic properly before considering the issue in this present note.
The scope of the management API (JMX) is typically that of the Cell (WebSphere), Domain (Weblogic) or Partition(JBoss). RES components that interact directly with the RES Console management stack normally expect to find exactly one RES Console within the this management scope : an error can arise from not finding a RES Console management stack, as well as finding more than one.
Resolving the problem
Certain use cases are supported that involve deploying more than one RES console in a cluster, most notably for situations where a active/passive fail over is needed, see the following document for more information: Clustering Rule Execution Server (RES) management console
However there is a number of limitations that one can face when several RES consoles are deployed within the same administrative cell, such as :
- The use of the API
ilog.rules.session.IlrManagementSession(reference) may fail with a
java.lang.IllegalStateExceptionas per the symptom above. In this situation, the only option is to deploy a single RES Console per cell.
- With JRules 6.x deploying RSM in a cell where more than one RES console is deployed can lead to
java.lang.IllegalStateExceptionas per the symptom above when attempting to add an SSP through the RSM console.
- With JRules 7.x DVS scenario suite executions initiated from Rule Studio to be run on a remote Java EE server in a cell where more than one RES console is deployed may fail with
java.lang.IllegalStateExceptionas per the symptom above.
- The use of interceptors (i.e. IlrSessionInterceptor implementations) may fail with a
java.lang.IllegalStateExceptionor an error message such as
ilog.rules.res.session.interceptor.IlrSessionInterceptorException: Unable to find RuleApp /myruleapp/myruleset for use by the interceptor. In this situation, the only option is to deploy a single RES Console per cell.
For situations 2. and 3. note that DVS and RSM are normally deployed in a non-production environment since they support the testing process of the rules prior to their deployment to production. So in practice it is not necessary to deploy multiple RES console instances for fail over purpose when in a testing environment. The recommendation is then to set up RES console and SSP in a testing cell that is separate from the production cell. In this testing cell, only one instance of RES console should be installed.
|Business Integration||IBM Operational Decision Manager||Platform Independent||8.5, 8.0.1, 8.0, 7.5||Enterprise|