8 Remote Debugging

So far, we have only used Ozcar to debug threads running in the same process as the debugger itself. However, Ozcar also supports the same features for threads running remotely, and thus also the debugging of distributed applications.

Model

In this case, debugging is a client/server application. The debugger itself (i. e., the site where the user interface is running) doubles as a server, accepting connections of clients (i. e., debugging sessions on remote sites). Clients forward events to the server, for example when threads stop at step points or become blocked. All attached threads, whether remote or local, are displayed in the same thread forest: Nodes corresponding to remote threads will be named by their site name and process ID in addition to their thread ID. All control operations are supported on remote threads: Commands are sent to the corresponding site so that the actual operations can be carried out locally.

Reflection

Note that when inspecting remote stacks, any contained values will be reflected before they are displayed. This means that an approximating copy will be made on the remote site and the debugger will only be able to operate on the copy.

Chapter Structure

This chapter will first take a look at how the server is started, then at how remote debugging sessions are initiated and how clients connect to the server.

8.1 Starting the Server

There are two ways to start a server: using the user interface or the API.

Using the Menus

In the Ozcar menu, you'll find an entry called Start Server. Activating this will cause Ozcar to open a port where it listens for clients that want to connect. This port is identified by a ticket: a string describing the server's location on the net. Clients will need this ticket in order to connect. A dialog will be opened showing the ticket. You can use ``copy and paste'' to create clients.

Using the API

Another way to start the server is to use the API, for instance to start the server automatically from your application or to implement automatic connection of clients. The expression

{Ozcar.startServer}

will return the required ticket.

Multiple Activations

Once Ozcar has started its server, the server will live as long as the Mozart process it runs in. Clicking Start Server or evaluating {Ozcar.startServer} again will yield the same ticket.

8.2 Connecting a Client to the Server

Once a server has been started, clients can connect to it. Again, there are two ways to start a client: using the ozd application or the API. Note that you should not have started Ozcar on the site where you want to start a server: Both debuggers will attempt to take over control of threads and will confuse each other.

From the Command Line

The command line debugger can be used to start a client:

ozd --remotedebugger --ticket=ticket url -- args

This will use ticket to connect to the server. Otherwise, behaviour is similar to ozd --debugger, see Chapter 4 of ``Oz Shell Utilities'' for more information.

Using the API

The API provides the module OzcarClient at URL x-oz://system/OzcarClient. This can also be used to start a client:

{OzcarClient.start Ticket}

Fault Handling

When a client dies, the server will still consider its threads attached. Only when you invoke an operation on a thread will it notice this fact and consider the corresponding thread dead.