1 / 20

Department of Computer Science Courant Institute of Mathematical Sciences New York University

Department of Computer Science Courant Institute of Mathematical Sciences New York University. Filterfresh: Hot Replication of Java RMI Server Objects Arash Baratloo, P. Emerald Chung, Yennun Huang, Sampath Rangarajan, and Shalini Yajnik. Bell Laboratories Lucent Technologies.

chavi
Download Presentation

Department of Computer Science Courant Institute of Mathematical Sciences New York University

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. Department of Computer Science Courant Institute of Mathematical Sciences New York University • Filterfresh: Hot Replication of • Java RMI Server Objects • Arash Baratloo, P. Emerald Chung, Yennun Huang, • Sampath Rangarajan, and Shalini Yajnik Bell Laboratories Lucent Technologies

  2. Filterfresh Goals • Support highly-available RMI services in presence of failures • Handle crash failures • Transparent failure masking • Easily integrate into Java RMI

  3. Roadmap • Goals • RMI Registry architecture & crash failures • RMI architecture & crash failures • Process group approach to fault tolerance • Highly available registry service • “Reverse lookup” for masking (state-less) servers failures • Towards highly available servers • Conclusions

  4. RMI in a nutshell • Step 1: a server object registers with the RMI registry running on the local host • Steps 2-3: Clients get server’s remote reference by performing a lookup operation at a known registry • Step 4: Given a remote reference, clients invoke server’s methods through RMI

  5. Limitations of RMI Registry • Single point of failure • Clients need to know a priori which registry to contact • Does not allow multiple RMI servers to register under the same service name • Not suited for replicated highly-available RMI server objects

  6. RMI Architecture • The programmer writes the client and server application codes • The RMI compiler (rmic) generates the client stub and server skeleton • The RMI package implements the RRL and transport layers • Transparent masking of failures must occur below the stub/skeleton levels

  7. A unified solution • Fault-tolerance based on process group approach • Non-faulty processes form a logical group • Members interact using a set of group primitives • Group primitives are guaranteed to be reliable -- all or nothing • Group primitives are guaranteed to be ordered • Group members have a consistent view of other group members • Applications built on process groups view events in a synchronous fashion: • The group view changes for all members as though it is instantaneous -- synchronous • Events (e.g, send & receive of multicasts) occur in a logical order, within the same view • Members have the same view of the group

  8. Fortunately • Process group approach is • Well studied • Well defined protocols • Process group approach has been used in building general purpose fault-tolerant • Middle-ware systems, such as Horus/Ensemble, Transis, etc. • Services, such as FT directory and file servers • OO systems, such as ISIS+ORBIX, Electra, Orca • Java middle-ware systems such as iBus • Seems a good candidate for FT RMI services

  9. Basis for process groups • A GroupManager Class • 100% Pure Java • built on top of UDP/IP • Implements • Group creation • Join operation (with atomic state transfer) • Leave operation • Group multicast operation • Failure detection and recovery • All events are reliable and totally ordered

  10. Performance of group multicast • PentiumPro 200, Linux 2.030, Fast Ethernet connected by a hub • JDK1.1.1 • Thread and object serialization influenced the performance?

  11. Roadmap • Goals • RMI Registry architecture & crash failures • RMI architecture & crash failures • Process group approach to fault tolerance • Highly available registry service • “Reverse lookup” for masking (state-less) servers failures • Towards highly available servers • Conclusions

  12. FT Registry architecture • Embedded a GroupManager class to ensure reliable ordered events • Reliable and ordered group operations ensure consistent state • Replicated registry service for high availability • Supports dynamic joins w/state transfer • Detects and removes failed registry servers

  13. Bind operation • Bind operations are sent to every replica • Reliable multicast ensures every replica receives the event • Ordered group operation ensures consistency even if a new replica joins

  14. Lookup operation • Lookup operations are handled locally • Provides location transparency to clients • able to locate servers registered at unknown hosts • no need to have a priori knowledge of server’s host

  15. Performance of FT Registry • PentiumPro 200, Linux 2.030, Fast Ethernet connected by a hub • JDK1.1.1

  16. RMI & FT Registry • Supports multiple replicated servers to register under the same service name • Object references remain valid after the associated object has failed

  17. In the event of server failure • The failure is detected below the stub level, and ...

  18. Failure recovery forstate-less servers • A “reverse” lookup returns the name of a given wire connection • The old connection is patched with a connection to a non-faulty server • The operation is re-attempted • Transparent to the client: illusion of a valid object reference

  19. FT server Architecture • Client has the illusion of a single server • In reality, a group of servers process clients requests • Operations are performed at each server, in the same order for consistency • Replicated servers for high availability

  20. Conclusions and future work • To provide high availability there is need for • A reliable registry service • A reliable RMI architecture • Showed suitability of process group approach by • Transparently masking failures • Easily integrated our services into Java RMI • Future work • Complete work on general-purpose FT services • Address nested RMI calls for replicated servers

More Related