This discussion is archived
1 2 Previous Next 16 Replies Latest reply: Jul 27, 2010 5:57 PM by EJP RSS

Lookup remote object without using a Registry

843793 Newbie
Currently Being Moderated
Hello all,

I was wondering - is there a way to lookup a remote object published on know port without using the Registry?

For example, if some object implemtents Remote and being published in the following way:

Remote stub = UnicastRemoteObject.exportObject( someRemoteObject, 12321 );
Naming.rebind( name, stub );

Is there a way to lookup that object (host and port are known) without calling Naming.lookup() which locate the registry and query it for that object?

Thanks.
  • 1. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    No.

    There is a technique involving serialized stubs carted around via sneakernet, but it is hopleslessly impractical.

    Why do you ask?
  • 2. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    There is a technique involving serialized stubs carted around via sneakernet, but it is hopleslessly impractical.
    There is? Seriously? That's great, I want to marvel at that system (probably just for a few seconds, before I run away in panic).
  • 3. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    No.

    There is a technique involving serialized stubs carted around via sneakernet, but it is hopleslessly impractical.

    Why do you ask?
    I'm trying to load balance between two RMI servers using haproxy. I'm still fighting makeing it work and I thought that perhaps the fact that the client created against the registry instead of the published object makes this hard to implement (although I'm not sure in that). Can you tell the reason why the laguage does not support that?

    Can you add some details regarding the impratical way? I promise I won't use it on production... :-)

    Edited by: BarakY on Jul 26, 2010 3:26 AM
  • 4. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    I thought that perhaps the fact that the client created against the registry instead of the published object makes this hard to implement
    I do not understand.
    Can you tell the reason why the laguage does not support that?
    The language doesn't support RMI. The API supports RMI. A remote reference can only be acquired as the result of a remote method invocation. This presents a bootstrap problem to which the RMI Registry is the solution, and there is no other solution apart from sneakernet.
    Can you add some details regarding the impratical way?
    1. Get the remote object to serialize its stub to the disk when it exports itself.
    2. Get a diskette (remember them?), copy the stub onto the diskette.
    3. Transfer the diskette to the client via sneakernet.
    4. Copy the stub to the client's disk.
    5. Have the client software deserialize the stub.
    6. The client can then call remote methods on the stub.

    Note that this only works for a single instantiation of the remote object, unless it is Activatable. So you have to do that every time the server side comes up. So it is remarkably impractical..

    The Registry is basically a practical way of doing all that.

    The underlying issues are these:

    1. The remote object's host:port are put into the stub object at export time.
    2. There is no other way of getting that information into the stub, with the sole exception of LocateRegistry.getRegistry(), which uses internal magic to do it.
    3. Therefore there is no way for the client to get a usable stub.
    I promise I won't use it on production... :-)
    I know you won't, because you can't.

    Unless you use Activation ... but there are other problems with that, notably major security problems.
  • 5. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    Thanks for your detailed answer, although it made me sad - is it impossible to use tcp proxy in order to load balance RMI servers?
    ejp wrote:
    I thought that perhaps the fact that the client created against the registry instead of the published object makes this hard to implement
    I do not understand.
    This line of code:

    Remote proxy = Naming.lookup( "rmi://LB-MACHINE:1099/bindingName" );

    returns object which its toString() is:

    Proxy[IContract,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[10.80.0.212:46445](remote),objID:[-4062b568:12a0d5af1bd:-7ffc, 5556315565946931175]]]]]

    so the host and port and hardcoded, so the tcp proxy (which I intended to use as load balancer) does not really balances loads.
  • 6. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    Thanks for your detailed answer, although it made me sad - is it impossible to use tcp proxy in order to load balance RMI servers?
    I don't remember anybody saying that. I'm quite sure you can, but you'd have to integrate it with the Registry.
    so the host and port and hardcoded
    Correct.
    so ...
    That doesn't follow, nor does the other part about 'published against the registry', which i still don't understand.
  • 7. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    I don't remember anybody saying that. I'm quite sure you can, but you'd have to integrate it with the Registry.
    ...
    so ...
    That doesn't follow, nor does the other part about 'published against the registry', which i still don't understand.
    Sorry for not being clear enough, I'll try to explain better this time.

    My app is RMI based, and I would like to be able to run it on multiple machines, to support large traffic and failover in case of some machines got crash.

    For that purpose I'm trying to use haproxy, which is a tcp proxy, to be used as load balancer fronting those RMI servers. This proxy listens on port 1099 and forward requests to server A and B, both of them installed with the RMI app. Haproxy installed on machine LB.

    If a client lookup for the remote object, and use "LB" to specify the host (Remote proxy = Naming.lookup( "rmi://LB:1099/someBindingName" ); ), the object returned contains the host and port of one of the concrete servers (A or B, depends on the LB choice), and further method invocations on that remote object are not going through the LB, but directly to the concrete server, so load balancing is not done.

    My thought was, before I asked my question and you answered, that one can bind objects on known port (for example 11845), so client could lookup the remote object in the following way:

    Remote proxy = Naming.lookup( "rmi://LB:11845/someBindingName" );

    and since the registry is not involved, no host/port hardcoded object will be returned, and further method invocation will behave as regular tcp calls, so load balancing would be possible.

    I hope the background to my questio is more clear now.

    Can you suggest a way to load balance RMI servers? Am I on the right direction?

    Thanks.
  • 8. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    Sure, you can just keep going the way you are but have two Registries, i.e. just duplicate everything you would have an a single-server situation and stick the haproxy. in front of both Registries. QED.

    I also have a load-balancing Registry product if you're interested.
  • 9. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    Sure, you can just keep going the way you are but have two Registries, i.e. just duplicate everything you would have an a single-server situation and stick the haproxy. in front of both Registries. QED.
    Not sure I understand - server A and B run rmiregistry as well, and haproxy does listen to 1099 and forward the requests to that port - but the problem is the fact that the remote object hardcoded with host/port, isn't it?
    I also have a load-balancing Registry product if you're interested.
    Can you add some details or pointer to resources?
  • 10. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    Not sure I understand - server A and B run rmiregistry as well, and haproxy does listen to 1099 and forward the requests to that port - but the problem is the fact that the remote object hardcoded with host/port, isn't it?
    Why is that a problem? The haproxy load-balances between the two Registries, and the clients get remote objects from whichever Registry the haproxy gave them. If that's not what you want what is?
    Can you add some details or pointer to resources?
    Hmm. It's a Registry:

    (a) that can accept bind()s from non-local hosts, subject to a security .policy file so it isn't open slather
    (b) thatcan accept multiple binds for the same name provided the underlying remote type is the same
    (c) whose lookup() returns a stub that arbitrary calls any of the services that were bound under that name. So it's a lot more dynamic than the haproxy scheme above, which only load-balances at lookup() time.

    I wrote this several years ago & have forgotten some of the details; let me look into it some more.
  • 11. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    Why is that a problem? The haproxy load-balances between the two Registries, and the clients get remote objects from whichever Registry the haproxy gave them. If that's not what you want what is?
    You are right if the client app would create the remote object each time it need to invoke remote method. In my case the client app create the remote object once, cache it (to save lookup time), and every time remote method invocation is needed, it invokes the methods on that cached object. Now, as far as I understand, the tcp calls are not going to haproxy, but to the concrete server according to what hardcoded in the remote object.

    Am I right or totally wrong on that?
  • 12. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    You are correct, but at least the haproxy has load-balanced the Registries, and therefore the remote objects to some extent. If you want more you will have to do more, or buy more.
  • 13. Re: Lookup remote object without using a Registry
    843793 Newbie
    Currently Being Moderated
    ejp wrote:
    You are correct, but at least the haproxy has load-balanced the Registries, and therefore the remote objects to some extent. If you want more you will have to do more, or buy more.
    I would be glad to do more, if I only knew what. It seems like something built in the way Sun chose to implement this.
  • 14. Re: Lookup remote object without using a Registry
    EJP Guru
    Currently Being Moderated
    It is. The stub contains the host:port of the remote object.

    The question now is whether the load balancing you have already achieved is adequate. What you have so far is that every client of the Registry gets load balanced to a specific Registry, and stays talking to the corresponding server host and its Registry and remote object(s) thereafter. If you want load balancing per RMI call you have to talk to me off-list, it's non-trivial
1 2 Previous Next