Exceptions when Overriding Cluster Policies
In addition to handling the exceptions that may occur when sending a JMS message, a service that overrides a cluster policy must handle ISRuntimeExceptions that result when policy requirements are not or cannot be met. Integration Server throws an ISRuntimeException after attempting to override a policy for the following general reasons:
![*](bullet.gif)
The service sending the JMS message provided invalid data and the
Broker Server throws an exception.
Integration Server wraps the
Broker Server exception and rethrows it as an ISRuntimeException.
![*](bullet.gif)
The
Brokers specified in the
JMS_WMClusterNodes input parameter are not available.
Following is a list of situations in which Integration Server throws an ISRuntimeException while attempting to override the connection factory policy when sending a JMS message.
![*](bullet.gif)
The
JMS_WMClusterNodes specifies a single
Broker and that
Broker is not available. This applies to policies such as round robin, round robin weighted, random, and sticky.
![*](bullet.gif)
The
JMS_WMClusterNodes specifies multiple
Brokers and the policy requires that the JMS message be sent to one
Broker. This applies to the round robin, round robin weighted, random, and sticky policies.
![*](bullet.gif)
The cluster policy is multisend best effort and none of the
Brokers specified in
JMS_WMClusterNodes are available.
![*](bullet.gif)
The cluster policy is multisend guaranteed and one or more of the
Brokers specified in
JMS_WMClusterNodes are not available.
![*](bullet.gif)
The
JMS_WMClusterNodes specifies a
Broker that is no longer part of the
Broker cluster for the cluster connection factory.