Java RMI - registry questions

Discussion in 'Java' started by Christian Hvid, Aug 13, 2007.

  1. Can anyone help with these Java 5 RMI related questions?

    I want to make a very basic RMI application; something needs to run as
    a "background job" that I should be able to query the state of and
    start and shutdown cleanly.

    * Is there a clean way to shutdown a registry created locally in the
    server code?

    My code looks like this:

    public interface Hello extends Remote {
    public String sayHello() throws RemoteException;
    public void shutdown() throws RemoteException;
    }

    public class ServerTest implements Hello {
    public static void main(String args[]) throws RemoteException,
    AlreadyBoundException {
    ServerTest obj = new ServerTest();

    Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 0);

    Registry registry = LocateRegistry.createRegistry(2001);

    registry.rebind("hello", stub);
    }

    public String sayHello() throws RemoteException {
    return "Hello there";
    }

    public void shutdown() throws RemoteException {
    System.exit(0); // Other than doing something as violent as
    this?????????????
    }
    }

    public class ClientTest {
    public static void main(String args[]) throws RemoteException,
    NotBoundException {
    Registry registry = LocateRegistry.getRegistry(2001);

    Hello hello = (Hello)registry.lookup("hello");

    System.out.println("stub.sayHello returns "+hello.sayHello());

    hello.shutdown();
    }
    }

    I am looking for a call like:

    registy.shutdownInOrderlyFashion();

    * Why does rmiregistry need to have access to the class definitions of
    the interfaces?

    The alternative way of doing the above is to run the rmiregisty
    program seperately and get the registry by:

    LocaleRegistry.getRegistry();

    This works *only* if I start the rmiregistry program at the root of
    generated class files; presumably because the rmiregistry program
    needs to have access to the class definition of "Hello".

    While I get that can define a codebase or classpath to point
    elsewhere, I don't get why the rmiregistry program needs to have
    access to the class definitions?

    I as understand it, the rmiregistry simply should register the name
    "hello" for the server and resolve the name "hello" as a reference to
    something on the server for the client.

    Only the client and the server should need to know the interface
    definition.

    -- Christian
     
    Christian Hvid, Aug 13, 2007
    #1
    1. Advertising

  2. Christian Hvid

    Esmond Pitt Guest

    Christian Hvid wrote:
    > * Is there a clean way to shutdown a registry created locally in the
    > server code?


    Yes. Unexport it. Make sure you keep the Registry reference returned by
    LocateRegistry.createRegistry, then you can just pass that to
    UnicastRemoteObject.unexportObject().


    > * Why does rmiregistry need to have access to the class definitions of
    > the interfaces?


    Because it receives the stub via an RMI call. That means that it has to
    be able to deserialize the stub, and to deserialize the stub it needs
    the remote interfaces, and the closure of any other application classes
    the remote interface depends on.

    > I as understand it, the rmiregistry simply should register the name
    > "hello" for the server and resolve the name "hello" as a reference to
    > something on the server for the client.


    It doesn't do that. It resolves the name as a remote stub which it is
    holding in its own JVM space (in a Map<String, Remote>). The stub in
    turn contains stuff that refers to the remote server object, i.e. its
    {IP, port}, its objectID.
     
    Esmond Pitt, Aug 14, 2007
    #2
    1. Advertising

  3. On Aug 14, 3:07 am, Esmond Pitt <>
    wrote:
    > Christian Hvid wrote:
    > > * Is there a clean way to shutdown a registry created locally in the
    > > server code?

    >
    > Yes. Unexport it. Make sure you keep the Registry reference returned by
    > LocateRegistry.createRegistry, then you can just pass that to
    > UnicastRemoteObject.unexportObject().
    >


    I did a bit of experimenting - this does not work:

    private static Registry registry;

    ....

    registry = LocateRegistry.createRegistry(2001);

    ....

    public void shutdown() throws RemoteException {
    UnicastRemoteObject.unexportObject(registry, true);
    }

    But this did:

    public void shutdown() throws RemoteException {
    UnicastRemoteObject.unexportObject(this, true);
    }

    Maybe that was what you meant?

    Anyway; what are good (simple) design practices for a basic RMI
    application like this?

    Is creating the registry as in the example ok or is there some other
    approach I should look at?
     
    Christian Hvid, Aug 14, 2007
    #3
  4. Christian Hvid

    Esmond Pitt Guest

    Christian Hvid wrote:
    > Maybe that was what you meant?


    No, it isn't what I meant. The former does indeed work subject to what I
    said: 'registry' must be the value returned by
    LocateRegistry.createRegistry() (because that is the actual Registry
    remote object). If it has subsequently become the value returned by
    LocateRegistry.getRegistry() it won't work (because that is a Registry
    stub).

    > Is creating the registry as in the example ok or is there some other
    > approach I should look at?


    I prefer creating the Registry inside the server JVM if possible: that
    way you avoid a number of headaches such as the shutdown problem and the
    Registry classpath problem.
     
    Esmond Pitt, Aug 15, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. HK
    Replies:
    1
    Views:
    3,697
    Cowboy \(Gregory A. Beamer\)
    Apr 1, 2004
  2. Replies:
    0
    Views:
    774
  3. Jan Schulze
    Replies:
    1
    Views:
    594
    Esmond Pitt
    Mar 26, 2005
  4. Mark Chao
    Replies:
    2
    Views:
    624
    E.J. Pitt
    Sep 9, 2005
  5. Replies:
    1
    Views:
    403
    Thomas Fritsch
    Sep 29, 2006
Loading...

Share This Page