1 / 17

Extending Java RMI for Dynamic Reconfiguration Presentation

This presentation discusses the extension of Java RMI for dynamic reconfiguration in a distributed system, including the motivations, solutions, and improvement achieved through XRMI.

waynep
Download Presentation

Extending Java RMI for Dynamic Reconfiguration Presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extending Java RMI for Dynamic Reconfiguration Presentation for ECE 8813 Georgia Institute of Technology Spring 2003 Christophe Levand

  2. CLIENT Java RMI RMI Registry ? myObj SERVER

  3. RMI Registry Naming.bind(“hello”, myObj) myObj SERVER Java RMI

  4. RMI Registry CLIENT Java RMI Naming.lookup(“hello”) • lookup returns the stub of myObj. • The stub code resides on the client.

  5. Java RMI • Stub on client / Skeleton on server • Stub/Skeleton responsible for parameters marshalling/unmarshalling. • Client uses the stub through an interface. The interface is implemented by the class of myObj. • The stub is following the proxy design pattern. • Consequence: Client uses the remote object as if it was “local”.

  6. Dynamic reconfiguration: Motivations RMI RMI Server A Server B Server C

  7. RemoteException ! ? RMI RMI Server A Server B Server C Dynamic reconfiguration: Motivations

  8. Dynamic reconfiguration: Motivations Solutions? • The client intercepts the Exception and makes a new lookup • Error handling is not transparent to the application. • Before moving the target component, one has to make sure that there is no ongoing transactions. • Extend the RMI middleware  XRMI. • From a static to a dynamic approach.

  9. Client Server Client Server lookup (1) Abstraction uses (6) uses (3) RMI Registry RMI Registry Component Manager Virtual Stub creates (2) forwards to (4) lookup (1) forwards to (7) uses (5) RMI lookup (3) RMI Stub RMI Stub creates (2) creates (4) XRMI RMI RMI vs XRMI

  10. RMI Registry RMI Stub XRMI: General perspective • Attributes of the virtual stub: • - ClientName / ServerName provided by the CM • A target reference provided by the CM. • Dependency list: • (client, server) • - lock flag: to block new invocations • invocation counter Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) RMI lookup (3) uses (5) creates (4) XRMI

  11. RMI Registry RMI Stub XRMI: Scenario 1 • Client needs to calls a method on the remote server object. • Lock flag is false, so a call can be made. • Virtual stub adds a dependency. • Virtual stub delegates the call to rmi stub (target reference), which forwards to server. • After the server sends the result back, Virtual stub removes the dependency. • Virtual stub returns the result to the Client. Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) RMI lookup (3) uses (5) creates (4) XRMI

  12. RMI Registry RMI Stub XRMI: Scenario 2 • Server needs to be moved to another location. • The CM on Server’s location broadcasts a query to all CMs in the network. • Each CM gathers a list of all its Virtual stubs that point to server. • For each Virtual stub of that list, set the lock flag to true: to block any new requests. • Each Virtual stub of that list monitors its dependency list and sends a signal to the CM when the list is empty. • Each CM sends a signal to the CM in Server’s location. Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) RMI lookup (3) uses (5) creates (4) XRMI

  13. RMI Registry RMI Stub XRMI: Scenario 2 • For each virtual stub used by server: • set lock to true • monitor the dependency list. • send a signal to the CM when the list is empty. • the CM moves the server to another location. • the CM broadcasts a signal to every CMs. • Each CM makes an RMI look up for the remote server and update the target reference in their virtual stubs that point to the old location. Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) RMI lookup (3) uses (5) creates (4) XRMI

  14. Client Server lookup (1) uses (3) forwards to (4) RMI Registry Component Manager Virtual Stub creates (2) RMI Stub XRMI local server XRMI: Improvement Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) • no RMI lookup • no parameter marshalling RMI lookup (3) uses (5) creates (4) XRMI remote server

  15. RMI Registry RMI Stub XRMI: Improvement • Attributes of the virtual stub: • - ClientName / ServerName provided by the CM • A target reference provided by the CM. • Dependency list: • (client, server) • - lock flag: to block new invocations • invocation counter •  when high, move client to the same location as server. Client Server lookup (1) uses (6) Component Manager Virtual Stub creates (2) forwards to (7) RMI lookup (3) uses (5) creates (4) XRMI

  16. RMI / XRMI cost comparison

  17. Resources • Xuejun Chen, Extending RMI to Support Dynamic Reconfiguration of Distributed Systems. Proceedings of the 22nd International Conference on Distributed Computing Systems, page(s): 401 – 408, 2002. • http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html

More Related