webMethods API Portal tutorial

As we seen in the previous article, loadbalancer is one of the crucial component of API Portal. In this article we will focus on few troubleshooting tips if incase you find difficulties in starting the loadbalancer.

Log files

Every component in API Portal stack will have a work directory( $$SoftwareAG\API_Portal\server\bin\work\ work_loadbalancer_s). The work directory usually contains 

1. Configuration files to run the component (for ex httpd.conf for running the Apache) ($$SoftwareAG\API_Portal\server\bin\work\work_loadbalancer_s\httpd\conf)
2. Log files ($$SoftwareAG\API_Portal\server\bin\work\work_loadbalancer_s\httpd\logs)
3. Data (if the application generates some data - for ex elasticsearch/ postgres would have the data folder)

If you have trouble in starting up loadbalancer, please check out the system.out.log in $$SoftwareAG\API_Portal\server\bin\work\work_loadbalancer_s\httpd\logs. The file would contain the default console logs from Apache HTTPD.

In some scenarios the httpd would not be even able to start due to environment library dependencies. In such case, it is worth to have a look at the CloudAgent log located in $$SoftwareAG\API_Portal\server\logs.

Some known issues

• RHEL 6.8

RHEL 6.8 platform the loadbalancer fails to start with below errors.

httpd: Syntax error on line 76 of /conf/httpd.conf: Cannot load modules/mod_authn_socache.so into server: httpd/modules/mod_authn_socache.so: undefined symbol: apr_global_mutex_lockfile

Solution

We need to remove "apr rpm" packages from the linux RHEL 6.8 env. We can query the packages using "rpm -qa | grep -i apr" and remove the packages using "rpm -e <package-name>"

• Azure Cloud environment

Loadbalancer fails to start due to lengthy hostname in Azure cloud environment. We have described in detail about the issue and solution in this article.