Skip to content

Troubleshooting

Review this page carefully before contacting our support team. You can find more information on the FAQ page.

If you haven't found a solution and need technical support, submit a request. Describe the issue in as much detail as possible, including the steps you took to reproduce or solve it. Also provide the log file, which can be found in the Face SDK Web API installation directory. This helps us find and fix the issue.

Bad License

  • Check if the regula.license file is in the expected location. The absolute path should be as follows: 
/app/extBin/unix/regula.license
  • Check if the container has access to the internet, at least to the https://lic.regulaforensics.com/ URL. In case a direct internet connection is not an option, configure Docker to use the proxy server.
  • Check if the license type is Online (supplied within the OLXXXXX.zip archive, not the SLXXXXX.zip one)
  • Check if the license is sufficient to request the needed number of workers. Each license is issued for a specific number of workers; thus, it is not possible to run the container if the number of requested workers exceeds the number defined in the license.
  • Contact us to check whether the license has expired or been deactivated.

Server Healthcheck

To retrieve server health information, including the application name, license ID, serial number, validity, and product version, use the /api/healthz endpoint. See Face SDK Web API for details.

Failing Healthcheck

Configuring application healthchecks is not a trivial topic. Our web service behavior makes this topic even more nuanced. On the one hand, it seems simple: query one HTTP endpoint, http://localhost:41101/api/healthz, which returns a JSON response with server health information.

However, there are a few factors that can cause a group of sequential checks to fail. One of the most common issues our customers face is overload during peak times.

Consider the following scenario:

  1. A web server with one worker is running under a load balancer.
  2. The web server backlog is 20 requests, and the load balancer performs a healthcheck every 30 seconds with a timeout of 30 seconds.
  3. 20 requests come in, 3 of them contain a bad image that extends processing to 5 seconds.
  4. The healthcheck request comes in and gets queued as the 21st request.
  5. To process the first 20 requests, the server needs 17 x 1 + 3 x 5 = 32 seconds.
  6. After a while, the healthcheck caller, that is, the load balancer, times out.
  7. The load balancer thinks your application is broken, marks the instance as broken, and terminates it or stops routing requests to it.

This can happen for any number of web servers under a load balancer. A host with an overload is terminated, giving other hosts more requests, causing them to timeout healthchecks and get released too.

To fix that, use the following options, or a combination of them:

  1. Increase the healthcheck timeout to 60 seconds or even higher. Thus, we trade off time to discover truly stuck nodes. If a web server on a given node crashes, the healthcheck fails fast with a connection error.
  2. Decrease the backlog size to 10 requests and let requests from a load balancer fail, triggering the load balancer to shift traffic to another instance earlier. In general, use the healthcheck timeout / 3 empirical formula to determine the desired backlog size.
  3. Increase the number of consecutive healthcheck failures required to trigger the load balancer to remove a node from routing.
  4. Increase the healthcheck period to 60 seconds or even higher. Thus, if a spike in load is not constant, the server has more time to free the backlog before the queued healthcheck.

Permanent Container Restart

  • Check if the allocated RAM is sufficient (at least 4.5 GB RAM per worker is required).
  • Check if the container has access to the internet, at least the https://lic.regulaforensics.com/ URL. In case a direct internet connection is not an option, configure Docker to use the proxy server.