In the part 1 of this discussion I talked about an option on how to maximize HA. In this part, I will discuss about some the limitations and how to address those limitations.
When you have added multiple gateway or intermediate Messaging Engine (ME) for applications to connect, there are few limitations that we need to consider or aware about.
- Message Consumers (eg MDB's) are still dependent on the ME that hosts the local queue point to retrieve the messages. So this means only producers will be able to connect and send messages but consumers will not be able to consume.
- Messages in transit (i.e message being sent from ME1 to ME3 or ME2 or ME3) can be liable to be unavailable if ME1 or ME2 becomes unavailable
- Applications will not be able to achieve Message ordering. Having multiple potential routes from the producing applications to the queue point or subscription will disrupt message ordering.
- The added hop of messages across multiple ME's will introduce latency and a reduction in performance. But this can be effectively addressed by tuning the configurations such that applications target the connections to ME3 (hosting local queue) directly, but in case ME3 goes down, applications can connect to either ME1 or ME2.
In any case, treating the cause itself is better so that we can reduce the ME failover time to a level where its unavailability is no longer an issue. The ME's restart is dependent on two important factors
- The number of destinations configured to the bus member of the ME
- The number of messages currently stored on the ME
Large number of destinations : It is important to ensure you do not define too many queues in a single Messaging Engine. It is wise to create multiple ME's and associate fair amount of queues to each one of them. In the event of the ME restarting, it tries to reload the references for each of the destination and publish that information with the work load manager, which can be time consuming.
Large number of messages: It is recommended to keep stored messages to as minimum as possible. The presence of large number of messages destination will impact the ME start time there by delaying ME's availability. Please note that messaging environment must not be treated as database to store large number of messages for long duration. You need to match your consumption rate with your production rate such that the queue depth is always minimal.