Have a requirement to send data from one LPAR to two (multiple) different MOI servers, how to accomplish this.
MOI 2.1
This can be done by simply configuring two separate MSS's for the LPAR each MSS pointing to a different MOI server.
Problems can occur if users attempt to configure two separate MOI severs for the same LPAR. This may not work because users had 'copied' the MSS deployment instead of creating a new one. The problem with copying a deployment is that it copies the server id and that is required to be unique for each server. If two servers with the same id connect to the hub, the connection of the second server is rejected.
More Details:
Problem:
Each message service server has a unique identifier called the server id. If multiple servers with the same server id try to connect to the hub only one is allowed to connect.
In the server log, the exception keeps repeating and there is no data flow from the server:
WARN [2024-xx-xx 17:00:00.253] [Message Service Server] - [org.apache.activemq.network.DemandForwardingBridgeSupport:serviceRemoteException:649] [ActiveMQ Transport: tcp://<hostname>/<ip_address>:<port>] - Network connection between vm://<MAAS Broker vm location> and tcp://<hostname>/<ip_address>:<port> shutdown due to a remote error: {}
java.io.IOException: ShutdownInfo {commandId = 1, responseRequired = false}
In the hub log, there is the following message about rejection of connect:
WARN [2024-xx-xx 21:00:00.224] [Message Service USS Hub] - [org.apache.activemq.broker.TransportConnection:processAddConnection:849] [ActiveMQ Transport: tcp:///<hostname>/<ip_address>:<port>] - Failed to add Connection id=<MAAS Broker vm location><message Service Hub Node location>, clientId=<ID><outbound location> due to {}
javax.jms.InvalidClientIDException: Broker: messageServiceHubNode - Client: <ID><outbound location> already connected from tcp://<ip_address>:<port>
Causes:
There are two causes most often seen:
1. A new server deployment is made by copying the files of an existing server. This copies the files that contain the server id to the new deployment and we end up with two servers with the same id.
2. The PDS member ZMSENVT2 did not get updated during a PTF application. PTFs after SO04859 use a simple text file to store the server id but require changes in the ZMSENVT2 member. If ZMSENVT2 does not have the required changes, the server may end up with wrong server id.
Note - This causes is very likely no longer applicable, the version discrepancy that causes this requires very old versions of MS that are seldom used.
How to resolve:
Check the contents of the PDS member ZMSENVT2 and verify that the following lines are there:
# Server Id config
IJO="$IJO -Dserver.id.config="
IJO="$IJO${MSINST}/broker/server-id.txt"
If these lines are missing copy the ZMSENVT2 member from the target libraries of the latest PTF and restart the server.
Ensure that the file <mount_point>/cfgb/instance/messageService/broker/server-id.txt is present in both servers and review the id inside (this is an ascii text file). If the server id is the same, delete one of the files contents (the contents of the directory including the server-id.txt file) and restart the server. A new unique server id will be generated. Note - Copying of libraries for creating new message service servers versus redeploying each new Message Service is not recommended due to possible conflicts with the same server connection ID's causing the the Message Server Hub multiple connection conflict, but it is acceptable if the above steps are followed.