Troubleshooting

This topic describes various VirtServer issues and how to avoid and fix them.

Brotli native library error messages

Issue

Customers upgrading to VirtServer 3.21.0 on Linux may encounter the following error message:

java.lang.UnsatisfiedLinkError: Failed to load Brotli native library

Cause

This error is typically observed on RHEL 9 Linux systems where the /tmp folder is not accessible due to security hardening measures. The Brotli native library fails to load because the /tmp filesystem is mounted without the necessary execution permissions.

Workaround

SmartBear is working on a permanent fix. In the meantime, follow these steps to resolve the issue:

  1. Modify the Temporary Directory:

    • Locate the VM options file at

      <virtserver-installation-folder>/bin/VirtServer.vmoptions

      Refer to the screenshot below for a Windows-based example. Ensure you modify the correct file for your operating system and setup.

      troubleshooting-modify-file-windows-based-example.png

    • Add the following line, replacing <some-folder> with a directory that has execution privileges for the Linux user running VirtServer:

      -Djava.io.tmpdir=<some-folder>

  2. Restart VirtServer:

    • After updating the VM options, restart VirtServer. Ensure you are using the appropriate VirtServer executable for your setup (application or service).

      Refer to the screenshot below:

      troubleshooting-selecting-appropriate-virtserver-executable.png

VirtServer does not send responses

If a virtual service doesn’t respond to incoming requests, then, most probably, it is not running, or it doesn’t receive these requests. So, –

If this does not solve the issue, see the VirtServer log to determine possible problems. You can find the log file in the <user folder>/.readyapi/logs/ folder.

Here are a few more possible reasons why a virtual service doesn’t send expected responses:

  • If your virtual service is behind a proxy or firewall, then it’s quite possible that requests don’t reach the service. Check the proxy (or firewall) settings to ensure the virtual service is “visible” to clients.

  • One more reason is that VirtServer cannot find one or more third-party libraries which your scripts use (virtual services use scripts for conditional routing, for choosing the dispatch strategy, and for other tasks). Make sure you put the library files to the <VirtServer folder>/bin/ext folder.

  • If you use routing, then it’s possible that VirtServer cannot get a response from the service to which you route requests. Verify that this service is available and there are no misprints in its URL.

Database file lock

Sometimes, the virt-server.h2.h2.db file stays locked after rebooting the computer, which does not allow launching VirtServer. This usually happens if VirtServer closed unexpectedly.

There are several ways to handle this situation:

  • The following method suggests creating a simple startup script before trying to connect to a database file:

    1. Create the unlock.sql file in the following directory:

      <user home directory>/.readyapi/virt-server

    2. Add the following line to the file:

      UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

    3. Open the virt-server.yml file located in <user home directory>/.readyapi/virt-server.

    4. In the url field, change the existing line with the following:

      url: jdbc:h2:file:~/.readyapi/virt-server/virt-server.h2;MV_STORE=FALSE;INIT=runscript from '~/.readyapi/virt-server/unlock.sql'
      virt-server.yml
      # H2 Database configurationsdatabase:
  # the name of your JDBC driver
  driverClass: org.h2.Driver

  # the username
  user:

  # the password
  password:

  # the JDBC URL
  url:jdbc:h2:file:~/.readyapi/virt-server/virt-server.h2;MV_STORE=FALSE;INIT=runscript from '~/.readyapi/virt-server/unlock.sql'

  # any properties specific to your JDBC driver:
  properties:
    charSet: UTF-8

  # the maximum amount of time to wait on an empty pool before throwing an exception
  maxWaitForConnection: 1s

...

    5. Save all the files you have edited and try to launch VirtServer. It should work properly.

  • Delete the virt-server.h2.h2.db file. VirtServer will recreate the file on startup thus fixing the issue, but all the configuration settings and working history will be lost. Not recommended.

Non-private connection issue

VirtServer works through the HTTPS protocol. By default, VirtServer comes with a self-signed security certificate, which modern browsers do not consider secure enough. So, they report about an insecure connection when you open the VirtServer web interface in a browser. The message you see depends on the browser you use, for example:

  • “Your connection is not private” in Chrome.

  • “Your connection is not secure” in Firefox.

  • “Safari cannot verify the identity of the website...” in Safari.

  • “Server Authentication. The server failed the authenticity check” in Konqueror.

  • “There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority.” in Internet Explorer.

You can ignore this warning and continue working with the VirtServer web interface.

–or–

You can install a security certificate for your VirtServer instance to avoid the warning. To do this, see Use Custom SSL Certificates for VirtServer.

See Also

In this section:
© 2025
Publication date: