1 / 18

A Replication Framework for Program-to-Program Integration across Unreliable Networks

A Replication Framework for Program-to-Program Integration across Unreliable Networks and its Implementation in a Servlet Container. Alberto Bartoli Milan Prica Etienne Antoniutti di Muro. DEEI – Università di Trieste. Building Blocks. Programmer code. JMiramare.

kane
Download Presentation

A Replication Framework for Program-to-Program Integration across Unreliable Networks

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. A Replication Framework for Program-to-Program Integration across Unreliable Networks and its Implementation in a Servlet Container Alberto Bartoli Milan Prica Etienne Antoniutti di Muro DEEI – Università di Trieste

  2. Building Blocks Programmercode JMiramare Replication algorithm JBora Group Communication Middleware (GC layer) Spread

  3. What JMiramare offers? • Operations from each client are executed in the • same order in which theywere issued by the client. • If the service replicaSR receives multiple copies of a given • update request,SR executes the operation only once. • Nota Bene: • Multiple copies of a given request could be received by different replicas; • There are NO assumptions about the “timing policy” of client • retransmissions.

  4. How it works? (Premises) • Data structures of the service replica are kept in volatile storage. • Data structures are replicated and kept in sync at all servers in the • primary partition. • Each client is connected to a single replica at a time. • A replica can execute a request only if it is up-to-date for that object. • If a replica is unable to execute the request, it redirects the client to • another replica.

  5. ... Premises • Each replica executes read operations locally. • A replica can perform updates only if it is a member of the group’s • primary partition. • Updates involve multicasting to the other replicas the new version • oftheobject and the last response sent to the client. • A client that does not receive the response for an update may • submit the very same request immediately. • Replicas that enter the primary partition must first gain the • up-to-date versionof server replica data.

  6. Implementation Issues

  7. Request: • Methodread / update • Paramsinput params of the method • objId • clientId system-wide unique identifier • serviceHandle[objId]counter of the successful • updates from that client

  8. Response: • StatusOK, UNABLE, UNKNOWN • Resultinvoked method return value • NewHandlenew value of the successful • updates counter • Alternativesnetwork addresses of some • of the service replicas

  9. Data Structures of a Server Replica: • objthe actual object replicas • versionTablenumber of updates applied to each • object (version number) • clientTablefor each (clientId, objId), • (lastVersionNumber, lastResponse) • canUpdateboolean flag,true only if the replica can execute updates • currVthe last view received

  10. Algorithm Overview • When a replica bootstraps, it spawns: • MainT() thread • Listening thread • When a new request comes in, the connection • is associated with a ClientSessionT() thread • ClientSessionT() thread processes each • request as follows:

  11. Execution Path of an HTTP Request Consistency Update Servlet Service Tomcat AXIS Not Up To Date localCall() Shared data between the MainT and the ClientT. Main Thread

  12. Main thread (Principal tasks): • Receives a message m from ClientSessionT() • // via grp.localCall() JBora • Multicasts m • Upon receiving the multicast m, updates the objectand • all necessary data structures • MainT() at the replica that sent the multicast also executes • grp.localRespond()// thus awakening the ClientSessionT(). • Handles view changes

  13. We want to figure out how to integrate our code with the common replication framework?

  14. JMiramare? ComponentMonitor ComponentHandle call() call() Replication Framework Proposal Proxy “Normal” Axis chain Handlers disabled static call() TxHandler WSMon Handler Service Object handleReq() handleReq() handleResp() handleResp() AXIS

  15. ?

  16. Request handling logic (detailed): Add Entry in ClientTab New Client ? Server Up To Date? Req = Read ? No Yes No req // update No Yes SERVICE resp <UNABLE, redirect> <OK, result>

  17. Request handling logic (cont.): Duplicate req? Can update? No Yes req // update Yes No resp <OK, result> <UNABLE, redirect>

  18. Request handling logic (cont.): GC Main Thread propagate() SERVICE Update (Copy) // can update Clone Obj. (Make a Copy) grp.LocalCall (to MainThr) req Yes No OK? resp Undo <OK, result> <UNKNOWN>

More Related