Location service or osfind hangs when osagent is on multi-homed host
Question:
The osfind command and the locatoin service hang when an osagent is running on a multi-homed host. After several minutes an ObjLocation::Fail exception is thrown. In some cases the hang appeared to be indefinite.
Answer:
The osagent was running on a multi-homed machine whose default interface is not accessible to the client application (osfind). The default behavior of the osagent is to set up the TCP client handler on all addresses. However, each client logs into the osagent an requests the address and port of the handler for subsequent communications. The osagent will by default provide the default host in the reply to the client. If the client cannot access that address then it will eventually fail to contact that osagent.
If a localaddr file is provided to configure the osagent, then the osagent will attempt to match the client subnet and reply with a compatible address if there is one. Otherwise is it will reply with the _first_ address found in localaddr.
If clients are on the same subnet as the osagent, but not on the subnet associated with the default host, then providing a complete localaddr file should be sufficient to solve the problem.
If clients are coming from other subnets, the localaddr must be carefully configured based on the application requirements such that the localaddr file limits the list of addresses to only those that are reachable by all potential TCP clients (osfind and location service). Such configuration requires knowledge of the specific IP address, network mask, and broadcast mask for each client machine and the host where the osagent is running. For example if the host has one non-default interface that is accessible to all potential clients, then configure loacaladdr to that one specific address. This ensures that even though the osagent cannot match the client network, it will return the first (and only) address from localaddr, which the client should be able to contact given the assumption made.
Note that the recommendation is very different for UDP clients (normal VisiBroker applications). If a localaddr file is provided to configure the osagent, then the osagent will attempt to match the client subnet and reply with a compatible address if there is one. Otherwise is it will reply with the _default_ address of the machine.
Thus there is an inherent limitation which applies to UDP clients running on separate subnets. These clients must be able to send UDP mesages to the default interface of the host that is running the osagent in order to communicate with that osagent. An alternative configuration is to run osagents on each subnet and bridge the subnets using the agentaddr file for each osagent as described in the product manuals.
Article originally contributed by