Server Issues

OPeNDAP server software resides on the same computer (in general) as the data being served. The OPeNDAP server will use some lower-level web server software (e.g., Apache Server or Tomcat) to make the actual connection to the Internet. Most web server software creates and maintains a log file of all the incoming (http, e.g.) requests, and some indication of the success and/or failure mode of the response. The log files are often in a standardized form but are individually configurable by the system administrator.

Most sites that are interested in the usage of their OPeNDAP server(s) have developed scripts they run, typically once per month, to derive "metrics" of the usage of their server. These "metrics" might include: number of hits, number of successful hits, number of repeat users, and volume of data delivered.

A typical place to look for the web server logs is /usr/local/apache/logs but the actual location depends on how and where the server was installed. Check with your system administrator for the specifics on your machine.

You can find more information on Apache's server software at http://www.apache.org, including more information on log files.

There are also log analysis packages available that could be useful.

There are several ways to test a DODS server. One of the simplest ways is to use any web browser to look at a dataset. For a description of how to do this, see our description of how to access DODS data with a browser.

You can also test out a server by using the 'geturl' tool. It should be in your $DODS_ROOT/bin directory. To use 'geturl', give it the -d, -a, or -D option and the URL of your dataset. For instance,

• geturl -d

Yet another way to test and debug a server is to directly connect to the HTTP server. Thus bypassing *all* interpretation of the return data stream, both from the DAP and the libcurl (HTTP) library. Here's the procedure. Type the following, making the substitutions for the server/URL you want to debug:

• telnet <host with server> 80 (assuming the server is running on port 80, substitute the correct port otherwise).
• GET <URL fragment following the hostname> HTTP/1.1
• Host: <hostname>
• <blank line>

Following the blank line you will see the response from the server, including the response headers.

What's going on here? This technique uses telnet to communicate with the HTTP daemon. The '80' causes telnet to use port 80 (the port normally used for HTTP). The first line instructs the HTTP daemon that it should GET the named document (the path used for the second argument is relative to the server's DocumentRoot) and use HTTP/1.1. Following the GET line there are one or more HTTP/1.1 headers which supply additional information to the server. HTTP/1.1 only requires that the Host: header be present. There are other request headers you can use. Consult the HTTP/1.1 specification.

Here is an example. The matching URL is http://test.opendap.org/dap/data/nc/fnoc1.nc.dds

        [jimg@comet jimg]$ telnet dodsdev.gso.uri.edu 80
        Trying 198.116.10.229...
        Connected to dodsdev.gso.uri.edu.
        Escape character is '^]'.
        GET /dods-test/nph-dods/data/nc/fnoc1.nc.dds HTTP/1.1
        Host: dodsdev.gso.uri.edu

        HTTP/1.0 200 OK
        XDODS-Server: DAP/3.4.2
        Date: Thu, 08 Jul 2004 17:01:59 GMT
        Last-Modified: Mon, 15 Apr 2002 22:49:39 GMT
        Content-type: text/plain
        Content-Description: dods_dds

        Dataset {
            Int16 u[time_a = 16][lat = 17][lon = 21];
            Int16 v[time_a = 16][lat = 17][lon = 21];
            Float32 lat[lat = 17];
            Float32 lon[lon = 21];
            Float32 time[time = 16];
        } fnoc1.nc;
        Connection closed by foreign host.
        

A few things to think about if your server isn't working:

• Check the permissions on your CGI scripts. They must have execute permission.
• If you are using a FreeForm server, see the question Why can' I get my FF server to serve my data?

To build the Matlab server, your entire DODS build (actually, just dap, packages, and ml-dods) must be in the same architecture as the Matlab libraries (o32/mips2 or 64/mips4). We haven't yet succeeded at building all of DODS in either of these architectures. Here are our main problems:

• currently, gcc does not support o32 and
• we've run into some trouble linking 64 bit objects (problem with linker setup?)
• we haven't had time to work on this problem

To build the Matlab command line client, build in the same architecture as the rest of your DODS build. If that architecture does not match the architecture of the Matlab libraries (o32/mips2 or 64/mips4), the linking of loaddods.mex* will fail. Because loaddods.mex* is the only piece of the Matlab client that links to the Matlab libraries and it does not link to the DODS libraries, it can be built in the architecture of the Matlab libraries even though the rest of DODS is not. To build loaddods as either o32/mips2 or 64/mips4:

• Note: gcc does not support '-mabi=o32' but will build '-mabi=64'. However, SGIs cc supports both '-o32' and '-64'.
• edit Makefile
  • if using cc, add '-o32' or '-64' to CFLAGS;
  • if using gcc, add '-mabi=64' to CFLAGS;
  • remove '-gstab' from CFLAGS; and
  • change CC to 'cc' or leave as 'gcc';
  • make sure LDFLAGS points to the correct Matlab library (in case you have both architectures installed on your machine)
• remove (or rename) loaddods.o, variable.o, queue.o, extend.o, error.o, MLVars.o (new as of 3.1.4), and process_values.o (new as of 3.2.x);
• run '$MAKE loaddods'.