Java Reference
In-Depth Information
security manager must be running. The method then tries to locate the RMI registry running
on the default port (1099) of the named host. If that registry is found, we then look up the
StatRecorder
server using the name
Recorder
(which we knew in advance). If such a server
is running, this method will return the proxy object that is returned by the
lookup()
call. If
there is a problem—either because of the network, a registry not being found, or no server
registered under that name—an error message is sent to the console and
null
is returned.
There are a number of agreements that the client and the server in this system need to make
as part of their configuration. The client needs to know the name of the machine on which
the server is going to run and the port for the registry on that machine that corresponds to the
registry that the server is going to use. The client also needs to know the name under which
the server is going to register. These agreements are not specific to RMI; they are part of boot-
strapping any distributed system. There are ways of minimizing these agreements (such as
UP&P, Jini, or various web service systems), but the same set of problems needs to be solved.
We also have not supplied a very good way of handing the exceptions that might happen in
our system. We could, for example, deal with the
RemoteException
thrown when trying to
register our
StatRecorder
server by creating a new registry in which we could then export
our proxy object. Likewise, on receiving a
RemoteException
in the client, we might try some
other host or some other port to find a registry that contains a server named
Recorder
. How
we deal with such exceptions will depend very much on our application, and will have a large
impact on how failure-resistant our application is going to be.
Often, the problems that cause a
RemoteException
to be thrown have nothing to do with the
way a program is written, and everything to do with the environment in which the program
is run. RMI is really a part of Java that lets you build systems of programs rather than just a
single program, so the environment in which that system is running is often the cause of hard-
to-diagnose problems. For example, our approach to exporting our server assumes that the
RMI registry is running on the default port. If there is no registry running when we construct
our
StatRecorderImpl()
, or if there is a registry running on a different port, we will get a
remote exception, and on looking at the stack trace, will see that the exception was thrown be-
cause the connection to the registry was refused. In fact, there was no registry there to accept
the connection.
A more common, and often more frustrating, cause of a
RemoteException
being thrown has
to do with a class-loading failure on the part of the registry. But understanding that failure and
how to avoid it requires that we first learn some of the mechanisms that form the support for
RMI. We will start with the way RMI sends objects, both parameters and return values, from
one virtual machine to another.
