Odyssey Applications

This is being replaced by a new system based on Python and PostgreSQL. See OdysseyApplications3 for details.

This is a system for creating web and command-line database applications in a consistent framework. It consists of the following pieces:

• OdysseyAdapter programs - small programs written in C that connect web servers and the command line to Java virtual machines.
• OdysseyJavaVirtualMachines - JVMs run Java code that implements the specific applications.
• Database server - at present the data are stored on database.cs.

By far the most important package is the odyssey-2 package, which is described in PackageDocumentationOdyssey2.

Architecture

JVMs

The system consists of a "server" JVM that runs persistently on one machine, with "client" JVMs that run persistently on behalf of individual users on the various web servers. Additionally, there are "local" JVMs that run persistently under the identities of the individual users but otherwise are like the "client" JVMs.

By "persistently" we mean that the JVMs are started by a request, but continue to exist after that request has completed, and are re-used by future requests. However, they may be configured to terminate after a period of inactivity and will automatically be re-started by a future request. If a machine goes down, terminating one or more JVMs, no special harm will be done; the JVMs will simply restart as soon as a request comes in after the machine comes back up.

The automatic termination is handled by an instance of class WatchdogThread and is configured by including an invocation of the watchdog method in the setup method of the application instance. This is done in content.local, content.client, and content.server, per region. OdysseyJavaCode has information concerning where to find the source code. Whenever the watchdog wakes up, it checks the set of requests active on the instance. If there are no active requests on two successive checks, it initiates termination of the server. The actual termination should be reliable, but if a request gets “stuck” somehow, then the watchdog will never observe the request set to be empty.

Connection to User

The "client" JVMs connect to the webserver by a small CGI written in C. The "local" JVMs connect to the web server the same as "client" JVMs, and to the command line by a small program written in C. The "client" and "local" JVMs connect to the "server" JVM by socket connections that are established upon startup.

Connection to Database

All communication with the database takes place via the “server” JVM. Upon startup, it opens a connection to the MySQL server. Details are at OdysseyDatabaseDetails.

Available Applications

Web Applications

These applications are standard Web applications such as might be implemented using a PHP CGI or something comparable.

• OdysseyApplicationCSTeachPref: CS Teaching Preference Form (this is being moved to a PHP CGI implmentation by Omar Nafees)
• CS Graduate TA Management System - (in production use but entirely undocumented. Initial investigations by Daniel Allen in ST#86921 and ST#87447)
• OdysseyApplicationWebsiteMenuEditor: (www.cs); part of the LookAndFeelImplementation.
• OdysseyApplicationCSEvents - CS Events

Local Access Applications

These applications provide services that require access to the user's local system account. This is done by using websuid to run the client JVM under the user's local system account, instead of webgate. There is a "front page" that provides access to all of these applications (www.student.cs, www.cs).

Apache configurations

• odyssey.student.cs.uwaterloo.ca apache configuration is controlled on services08.student.cs by /software/wwwapache-1.3_server/config/httpd.conf
• odyssey.uwaterloo.ca apache2 configuration is controlled in the core region by /software/odyssey-3_apache/config/sites-available/odyssey

At present no data storage is associated with these applications; they simply provide a Web interface to some Unix command-line activities.

• Assignment Submission (www.student.cs)
• Disk Quota (www.student.cs, www.cs)
• XAS Account (www.student.cs)
• LP Quota (www.student.cs, www.cs)
• Mail Forwarding (www.student.cs, www.cs)
• File Access (navigate to home directory from front page mentioned above)

Routine Maintenance

The Odyssey system should not require much routine maintenance. It is designed to just keep working smoothly without specific attention being paid.

There are a couple of exceptions at present, which should be removed over time as improvements are made:

• Log files need to be cleaned out occasionally. A substantial volume of logs will accumulate in the log directories. Since a new directory is used for each day, the accumulation does not cause a "needle in haystack" problem, but the sheer volume will eat up progressively more disk space.
• Adapter program processes seem to accumulate sometimes. Under certain circumstances they can become defunct and hang around indefinitely. This also goes along with extra .resp files hanging around in the connect directory. Cleaning out all the .resp files and zonk ing processes owned by odyssey once in a while is not a bad idea. I believe that a further improvement to the adapter to time out waiting for access to the JVM FIFO will reduce incidents of this to nearly nothing.

ST#56596 is for automating cleanup.

Building a new Application

Building a new application is normally done entirely by creating new Java code to implement the application, and then editing the content.client and content.server classes to publish an instance of the application on a web server at a specific URL.

Here is a brief list of the typical steps:

• Create a new package in the uw package, say uw.newapp.
• Create an SQL database on database.cs, and create the data model in the database.
• Create a database interface, together with a database implementation which implements the interface methods by modifying the SQL database, and a security implementation which checks whether or not the requesting user is authorized to do that action.
• Create a web front-end to the interface by writing web request handler classes.
• Update content.server to create an instance of the database interface upon server startup.
• Update content.client to link in the web front-end to a specific location in the URL structure.

Notes from Isaac's December 2008 Briefing

NotesOnOdysseyApplicationsDecember2008