Using WAS sample custom advisor

A sample custom advisor for WAS is included in the <install_path>/servers/samples/CustomAdvisors directory.

Two files are used to implement the advisor: ADV_was.java: The custom advisor code that should be compiled and executed on the Network Dispatcher machine. LBAdvisor.java.servlet: The servlet code (it must be renamed to LBAdvisor.java) that should be compiled and installed on the WAS machine.

The servlet returns the following string in case of success:

LBAdvisor/0.92 100 Fri Dec 13 16:05:35 EST 2002

The advisor parses the string to get the WebSphere status (100) and informs the Dispatcher monitor.

Notes: We modified the Java file ADV_was.java to reflect our settings.
	To reflect the new advisor name, the line:

static final String ADV_WAS_NAME = "was";

was changed to:

static final String ADV_WAS_NAME = "was5"; To reflect the response of IBM HTTP Server on AIX, the line:

static final String HTTP_GOOD = "HTTP/1.1 200 ok";

was changed to:

static final String HTTP_GOOD = "HTTP/1.1 200 OK"; To reflect the location, where you have deployed the LBAdvisor servlet, the line:

static final String SERVLET_LOCATION ="/servlet/LBAdvisor;

was changed to:

static final String SERVLET_LOCATION ="advisor/servlet/LBAdvisor;

To check whether the appserver was able to serve a servlet request, we installed a simplified version of the advisor servlet on our sample topology, which always returned a status of 100, following these steps:

1. Create an appserver for the advisor on server app1 (Advisor1).

2. Configure and deploy the advisor servlet to respond to http://10.20.10.100/advisor/servlet/LBAdvisor. The advisor used the address configured for the cluster (10.20.10.100) to request the servlet, so it had to be included as a host alias for the appserver virtual host on our WebSphere configuration.

3. Create a cluster (AdvisorCluster), add existing appserver Advisor1 as a cluster member, then add a new cluster member (Advisor2) on server app2.

4. Regenerate the plug-in configuration.

Transfer the plug-in configuration file, <WAS_HOME>/config/cells/plugin-cfg.xml, to the corresponding directories on the Web server machines (web1 and web2 in our case).

5. In order not to use plug-in workload management to access the advisor servlet, configure the transport information tags of the plugin-cfg.xml files on each machine, so that each Web server sends requests to one appserver.

We located the original cluster definition in the plugin-cfg.xml file, as shown in Example 4-3.

Example 4-3 Original cluster definition in plugin-cfg.xml

<ServerCluster Name="AdvisorCluster">

        <Server CloneID="u85bjrri" LoadBalanceWeight="2" Name="Advisor2">

            <Transport Hostname="app2" Port="9083" Protocol="http"/>

            <Transport Hostname="app2" Port="9446" Protocol="https">

                <Property name="keyring" value="C:\Program 	 Files\WebSphere\AppServer\etc\plugin-key.kdb"/>

                <Property name="stashfile" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.sth"/>

            </Transport>

        </Server>

        <Server CloneID="u85bjt1l" LoadBalanceWeight="2" Name="Advisor1">

            <Transport Hostname="app1" Port="9085" Protocol="http"/>

            <Transport Hostname="app1" Port="9448" Protocol="https">

                <Property name="keyring" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.kdb"/>

                <Property name="stashfile" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.sth"/>

            </Transport>

        </Server>

        <PrimaryServers>

            <Server Name="Advisor2"/>

            <Server Name="Advisor1"/>

        </PrimaryServers>

    </ServerCluster>

We directed all the HTTP requests from web1 to app1:9085 and HTTPS requests to app1:9448, as shown in Example 4-4.

Example 4-4 New cluster definition on server web1

<ServerCluster Name="AdvisorCluster">

        <Server CloneID="u85bjt1l" LoadBalanceWeight="2" Name="Advisor1">

            <Transport Hostname="app1" Port="9085" Protocol="http"/>

            <Transport Hostname="app1" Port="9448" Protocol="https">

                <Property name="keyring" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.kdb"/>

                <Property name="stashfile" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.sth"/>

            </Transport>

        </Server>

        <PrimaryServers>

                        <Server Name="Advisor1"/>

        </PrimaryServers>

    </ServerCluster>

We also directed all the HTTP requests from web2 to app2:9083 and HTTPS requests to app2:9446, as shown in Example 4-5.

Example 4-5 New cluster definition on server web2

<ServerCluster Name="AdvisorCluster">

        <Server CloneID="u85bjrri" LoadBalanceWeight="2" Name="Advisor2">

            <Transport Hostname="app2" Port="9083" Protocol="http"/>

            <Transport Hostname="app2" Port="9446" Protocol="https">

                <Property name="keyring" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.kdb"/>

                <Property name="stashfile" value="C:\Program Files\WebSphere\AppServer\etc\plugin-key.sth"/>

            </Transport>

        </Server>

              <PrimaryServers>

            <Server Name="Advisor2"/>

                    </PrimaryServers>

    </ServerCluster>

6. Test if the servlet is responding using http://10.20.10.100/advisor/servlet/LBAdvisor?debug=1. This option returns a HTML/text page with some diagnostic information.

7. Restart Load Balancer server:

dsserver stop

dsserver start

8. Start the custom advisor using the command:

dscontrol advisor start was5 80

where was5 is your custom advisor name and 80 is the port number, where the advisor opens a connection with the target server.

9. Start the GUI of Load Balancer and select your new advisor, then select the Current Statistics tab on the right. The advisor status is displayed. Click Refresh to update the status. If the advisor is working properly, the load value is displayed. If there is no response, a status of -1 is returned (see Figure 4-10).

Figure 4-10 WebSphere advisor status

If there is no response, one option is to select the Configuration Settings pane and change the advisor logging level to Advanced, for example, then look at the log file at <install_path>/servers/logs/dispatcher. A lot of detailed information is recorded, showing all requests and responses, which may help to locate where the problem is occurring.

If we simulate a failure by stopping the appserver on host was2 or disconnecting the network cable, we can see how the requests are directed to the available application server (associated to the web1 server). We can see the graphical statistics of the traffic by selecting the Monitor option under the cluster port the advisor is associated with, as shown in Figure 4-11.

Figure 4-11 Request distribution after one appserver becomes unavailable

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.