VirtServer - Troubleshooting

Issue

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

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.

     

     Click the image to enlarge it.

   • 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:

     

     Click the image to enlarge it.

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, –

• First of all, make sure you configured VirtServer and installed a license.

  Also, verify if VirtServer is able to run. If you run VirtServer as a service, make sure it is running.

• Then, make sure that you deployed your virtual service to VirtServer and that the virtual service is running.

• Check that the requests you send to the virtual service use the endpoint that matches the service’s URL:

  

  Click the image to enlarge it.

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.

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

     virt-server.yml

     # H2 Database configurations
     database:
       # 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.

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.