Building Your Event-Driven Architecture : Using Integration Server to Build a Client for JMS : Working with Cluster Policies : Overriding the Cluster Policy when Sending JMS Messages : Exceptions when Overriding Cluster Policies
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:
*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.
*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.
*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.
*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.
*The cluster policy is multisend best effort and none of the Brokers specified in JMS_WMClusterNodes are available.
*The cluster policy is multisend guaranteed and one or more of the Brokers specified in JMS_WMClusterNodes are not available.
*The JMS_WMClusterNodes specifies a Broker that is no longer part of the Broker cluster for the cluster connection factory.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback