In V10 of Integration Bus there are three methods of updating the additional instances on a given flow

  • Updating the bar file before deployment either in the toolkit or by applying bar-overrides
  • Using a Workload Management Policy
  • Using the java Integration API

In the production of the performance reports, we gradually scale up the number of instances on a given flow to try and get 100% utilisation. To perform the updates to the additional instances we use a small java application which uses the integration API to adjust the additional instances on a given integration server. Recently we have had a number of requests requesting further information on this tool. As a result of these requests we would like to provide you with a simple tool which can be used from the command line to increase the number of additional instances on a given Application / RestAPI/ message flow.

This tool requires the common set of jars that are required to run a Java Integration API Application

  • IntegrationAPI.jar
  • jetty-io.jar
  • jetty-util.jar
  • websocket-api.jar
  • websocket-client.jar
  • websocket-common.jar

The help provides information on the various ways the tool can be used:

Mandatory command options are:
i=localhost p=port n=additionalInstance [s=server {[a=application] [m=messageflow] | |r=RestAPI]]

Where:
localhost is the host name where the broker is running
port is the port number for the listener on the queue manager for the broker
additionalInstances are the number of additional instances to set for each matching message flow
server is the server to update
application is the application name to update
messageflow is the message flow name to update
restAPI is the RestAPI name to update
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10 s=MyServer
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10 s=MyServer m=MyMessageFlow
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10 s=MyServer a=MyApplication
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10 s=MyServer a=MyApplication m=MyMessageFlow
Example is : hursley.performance.tools.SetAdditionalInstances i=localhost p=2414 n=10 s=MyServer a=MyRestAPI

Below is an example of using this command:

java -cp IntegrationAPI.jar:SetAdditionalInstances.jar:jetty-io.jar:jetty-util.jar:websocket-api.jar:websocket-client.jar:websocket-common.jar hursley.performance.tools.SetAdditionalInstances i=localhost p=4414 n=16 s=Test

Output:

i=localhost
p=4414
n=16
s=Test
Connecting to broker at localhost=localhost, port=4414
Connected
IntegrationNode=TESTNODE_convery
-Skipping ServerName=default, is running=false
-Skipping ServerName=CallableFLowTutorial, is running=false
-Skipping ServerName=PreProd, is running=false
-Skipping ServerName=DevTest, is running=false
-ServerName=Test , is running=true
–No MessageFlows found for this ExecutionGroup
–No RestAPIs found for this ExecutionGroup
–Application=DemoApplication-Local–MessageFlowName=Demo_Local , AdditionalInstances=0 , is running=true
—Setting AdditionalInstances=16
—New AdditionalInstances=16

Flows changed =1
Flows not changed=0
Completed

Connected

To download this tool please follow this link –¬†SetAdditionalInstances.jar

5 comments on"Updating Additional Instance in IIB V10"

  1. Hi, you write:
    port is the port number for the listener on the queue manager for the broker
    but in example use port 4414 – http listener of broker in ibus 10,
    so we must use port of broker http listener?
    thanks

    • BenThompsonIBM January 25, 2019

      Hi,

      Thank you very much for your comment:- you correctly point out a problem with the help text of the utility provided.
      The port number which you should use is the web administration port for your integration node, which by default will be 4414.
      In case you’re interested … the reason why this mistake was made in the help text relates to the history of the API which is being used by the tool.

      In IBM Integration Bus version 9, you could connect to a remote integration node using the Java CMP API which provided a class MQBrokerConnectionParameters, which required, the hostname of the computer where the remote integration node, the port of its WMQ listener, and the name of the queue manager associated with the node. You can see an example of this code in the IIBv9 Knowledge Center: https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/be43130_.htm

      In IBM Integration Bus version 10, a new interface for connection to a remote integration node was provided in the Java CMP API called IntegrationNodeConnectionParameters. This interface requires the hostname of the computer hosting the remote integration node and its web administration port. You can see an example of this code in the IIBv10 Knowledge Center: https://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools.mft.doc/be43130_.htm

      So – apologies for any confusion … you should use the web admin port like in the examples.

      Cheers,
      Ben

  2. Is it possible to add a userid and password parameter. HTTP error code was -1

  3. This is something we may do in the future. The original reason we didn’t was to prevent internal configurable parameters being adjusted which would affect the result. This could have result in extra support calls due to incorrect diagnosis.

    Rob

  4. Is it possible to share a github repo rather than a JAR?

Join The Discussion

Your email address will not be published. Required fields are marked *