By Amir Najjar, Automation Development Lead
Working with a large scale Selenium Grid involves a lot of maintenance and support; as a result, it’s crucial to know how to retrieve data from your Grid and, in turn, learn more about how the Grid is actually performing.
For each Selenium Grid – whether it was configured as a local host or to use DNS or even an IP – you can make API calls to it and retrieve data from it.
First, you need to create your binding with the Grid inside your code; for our purposes, we used ActiveGridDeterminer. This Object should receive two parameters in the constructor, which are subject to change according to how you configured your Grid. The two parameters are:
• The hostname of the Grid – the IP/DNS of the hub (which could also be localhost for a local Grid)
• The port – 4444 by default
Once you have this information about your Grid, you can start invoking API calls on it. API calls will be built in the following form:
new URL(“https://” + gridHostName + “:” + gridPort + API_COMMAND);
Example: https://ec2-4-451-48-10.compute-1.amazonaws.com:4444
Below are two examples of data you could retrieve:
API_COMMAND = “/grid/api/testsession/”
If the returned HTTP status of this command is:
1. 500 Server Error: This indicates that the hub is busy.
2. 200 OK. This indicates that the hub is idle. The returned JSON will be:
• success: false,
• msg: “Cannot find test slot running session null in the registry.”
Note that if neither of these HTTPS statuses is returned, the hub might be down.
API_COMMAND = “/grid/api/hub/”
This command returns JSON data about the configurations you’ve made on the hub. This data is important for you to validate your configurations for large-scale Grids which were raised using automatic scripts.
Furthermore, the data which you use the most and which could be retrieved from a certain Grid includes the number of slots available in total, and the number of empty slots you currently have on your Grid.
The latter is important for implementing a load-balancer from within the automation code to direct tests to the less active Grid, where your cluster includes more than one Grid.
Example response:
• success: true,
• capabilityMatcher: “org.openqa.grid.internal.utils.DefaultCapabilityMatcher”,
• newSessionWaitTimeout: -1,
• throwOnCapabilityNotPresent: true,
• cleanUpCycle: 5000,
• custom: { },
• host: “7.4.48.12”,
• servlets: [ ],
• withoutServlets: [ ],
• browserTimeout: 90,
• debug: false,
• port: 4444,
• role: “hub”,
• timeout: 120,
• newSessionRequestCount: 0,
• slotCounts:
{
o free: 168,
o total: 168
}