MQTT message broker deployment options with IBM Engineering Lifecycle Management solution
Authors: TimFeeneyBuild basis: 7.0.3 and later
In IBM Engineering Lifecycle Management (ELM) 7.0.3 and later, there are four primary reasons why an MQTT message broker is needed.
- EWM or ETM clustering for user scalability
- Deep skew detection in global configurations of contributions from EWM SCM or RMM
- Live logging of running builds
- Building global configurations with contributions from other GCM servers (experimental)
- The MQTT message broker be clustered for both scalability and high availability purposes. See Configuring the cluster membership of an Eclipse Amlen server and Configuring your system for high availability. ELM provides several JMX MBeans that reporting on aspects of the MQTT message broker used by ELM. In particular, see the MQTT service metrics MBean in Common Managed Beans.
- Each ELM instance requiring an MQTT message broker should have its own independent cluster. For example: one MQTT message broker cluster in QA and one in production where each cluster is providing EWM and ETM clustering and GC deep skew detection.
- In cases where you are deploying the experimental capability to build global configurations with contributions from other GCM servers, you are required to share the cluster between ELM instances contributing to the common global configuration.
Deployment.MQTTMessageBrokerDeploymentOptions moved from Deployment.MessageSightDeploymentOptions on 2023-10-09 - 16:29 by TimFeeney -

Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.