Troubleshooting GAS configuration

Troubleshooting tips are provided for the most common issues encountered.

Proxy errors on Windows platform

On Windows®, if you see the error "Proxy refuses to start with socket error code 10038" in the proxy log, it means that the proxy refused to start and returned a socket error code of 10038. This can occur due to issues with the drivers provided by some third-party layered service providers (LSPs).

To rectify this situation, you need to run the following from the command line:

netsh winsock reset catalog

The command resets the Winsock Catalog to a clean state. Be aware that it might affect your installed applications that use the internet. You might need to reconfigure or reinstall such applications, so use the command cautiously. The command will ask to restart Windows.

Cannot find 127.0.0.1 or localhost on Windows

For users on Windows 64-bit machines who are using a network proxy, the browser cannot open 127.0.0.1 or localhost unless you modify your Advanced Network settings to avoid going through the proxy for these addresses.

What if the application doesn't start?

There are several reasons why an application does not start. Here are some basic troubleshooting procedures to follow as a standard approach to solving problems.

  1. Check the application configuration (xcf) file - to ensure that all components are set properly.
  2. The Genero Application Server creates separate log files for its dispatchers, proxies, and the DVMs started by those proxies. Examine the logs as they may provide you with some helpful information or error messages.
  3. Check your environment variables in $FGLASDIR/etc/as.xcf.
    Tip:

    You can get messages for the environment in the GAS log by setting the CATEGORIES_FILTER to CONFIGURATION.

  4. You may need to run the application in debug mode using the FGL debugger.

    To run the FGL debugger, the dispatcher must open a DOS command or an xterm window so that you can run the application with the fglrun -d command. For example, on Windows platform, start the dispatcher with the command to open a DOS window and override some of the settings for res.dvm.wa:

    httpdispatch -E res.dvm.wa="cmd /K start cmd"

    Before the application displays in the Web browser, a command window will open with all environment settings for that application. You can then manually run your application in debug mode, for example with fglrun -d progname to enter the command-line debugger (fgldb). The application will then display in the Web browser.

    Note:
    • You can use the graphical debugger in Genero Studio. For more information, see the Genero Studio User Guide.
    • The debug facility of the Genero Desktop Client includes logging and the debug console. For more information on using the GDC debug facility, see the Genero Desktop Client User Guide.
    • For details about debugging Genero Browser Client (GBC) applications, see Configure for GBC development and troubleshooting.

When you receive the Error: Runtime error. Try again ... page

Simply put, your application cannot start and you must check your application configuration. This error is typically the result of an incorrect path to the program executable.

Error taking session ownership

Here are some basic troubleshooting procedures to follow to help solve problems with GAS session ownership.

An error message is displayed in the dispatch logs when the GAS fails to take ownership of the session:

Failed to update the session lock file: 
     /Applications/fourjs/gas/3.20.04/appdata/session/httpdispatch/session.owner.
[fail]
Failed to take session ownership
These are some things that should help you isolate the problem:
  • Did you start the GAS using a different account to the one you used the last time? If so, check that the new account has permission to access the session.owner file. To resolve, set the appropriate permissions to the file.
  • Have permissions been granted to create the session.owner file? To resolve, set the appropriate permissions to the session directory.
  • Does your GAS have a multiple dispatcher configuration, and if so, is this the only GAS using this session directory? Check in the configuration file (xcf) of each GAS to ensure they are not starting with the same configuration for the session directories.

    To resolve, make sure there are different configuration settings for the appdata/session directory resources.