Planning broker servers
A broker server is a runtime system where a message broker runs.
For each broker server you plan to use, take the following into account:
- Each broker server requires its own message broker and queue manager, that is, a broker server cannot share a message broker or queue manager with another broker server.
- Each broker server must have a unique name. This name can have up to eight uppercase alphanumeric characters, and must start with an alphabetic character. To ease the association between a broker server and its corresponding message broker, it is recommended that you use the same name for both. The recommended naming scheme for broker servers and message brokers is to use the name of the related queue manager, and append the string BRK. For example, if the queue manager has the name MQM1, the broker server and message broker should both have the name MQM1BRK.
- Regardless of how many broker servers an instance contains, exactly one of them must be designated as the primary server in the customization definition. This is the server to which resources that apply to an entire instance are assigned.
- Each broker server must be prepared for use with FTM SWIFT. For information about how to do this, see Preparing a message broker.
- The DB2® subsystem to which a message broker is connected to must be in the same z/OS® image as the message broker.
- If you use FTM SWIFT and another product of the FTM family on the same message broker:
- Use execution group specific environment files instead of the broker wide
BIPBPROFas described in Preparing a message broker. - If you use multiple databases all have to use the same encoding scheme.
- If the database uses Unicode encoding scheme you need to adapt the deployment vehicle for resource class DB as described in Customizing an instance for which resources have not yet been deployed, step 20.
- Use execution group specific environment files instead of the broker wide
- For all execution groups that are to run customer-written flows based on the FTM SWIFT API nodes or the FTM SWIFT provided sample flows, you need to use the mqsichangeproperties command to set the Java™ stack size to at least 1048576 bytes, see Customizing an instance for which resources have not yet been deployed, step 23. If, when you test your message flows, you make heavy use of the FTM SWIFT nodes and experience "out of stack" exceptions, you might need to increase this value.
- If you plan to use the MSIF feature for file transfers, set the Java heap sizes as described here; otherwise, set the heap sizes
as described in the IBM® Integration Bus
documentation:
For an execution group, the default minimum Java heap size
(jvmMinHeapSize) is 32 MB and the default maximum Java heap size (jvmMaxHeapSize) is 256 MB. If you plan to use the MSIF
feature for file transfers, for each message broker in which instances of the
DNF_O_FT, DNF_O_FT1, DNF_O_FT2, or DNF_O_FT3 (referred to as DNF_O_FTx)
message flows run, set jvmMaxHeapSize to the value determined by the following
formula:
heap size = 314572800 x <number of instances of DNF_O_FTx>Note: 314572800 Bytes = 300 MBIf you want to optimize your settings, generate a garbage collector trace for a typical usage scenario and analyze the resulting data.