Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

  1. Split the rpc handling functions (and thus, corresponding helper functions) in Coordinator Service into multiple logical groupings.
    1. CoordinatorTabletManager - manages tables, tabletMap
      • createTable
      • dropTable
      • splitTablet
      • getTableId
      • getTabletMap
      • reassignTabletOwnership
    2. CoordinatorServerManager - manages serverList
      • enlistServer
      • getServerList
      • hintServerDown
      • sendServerList
      • setWill
    3. nothing extra (only call handlers)
      • recoveryMasterFinished
      • quiesce
  2. Think about how the functionality corresponding to each function gets spilt amongst different modules.
    1. All the rpc handlers - CoordinatorService
    2. Each handler:
      1. Receives / processes the rpc. - work1
      2. Then calls into the corresponding function residing in a separate module. - work2
  3. We will probably have another module, say CoordinatorServiceRecovery that does work workR
  4. Decide division of work between work1 and work2 (and similarly, between workR and work2). Options:
    1. work1 and workR function as dispatchers, real work done in work2.
      1. work1 - passes the rpc to the appropriate function for work2.
      2. workR - iterates over the log, passes each entry to the appropriate function for work2.
      3. work2 - does everything.
    2. Split according to the the recovery path.
      1. work1 - everything upto (and including) the first time a log is written to logcabin. This is the work that will be only ever done by the current leader (not the followers or the recovering leader).
      2. workR - iterates over the log, passes each entry to the appropriate function for work2.
      3. work2 - everything after work1.
  5. Look at the above options from decision-hiding perspective:
    1. First option:
      1. Decisions wrt how the log is read during recovery - workR (also knows how to read the opcode, but nothing more).
      2. Knowledge about format of log entries - work2
      3. Decision about when to write to log - work2
      4. Decisions wrt implementation of the function (in all the cases) - work2.
      5. Problem: work1 doesn't seem to hide any decision (its a dispatcher).
      6. Problem: Putting all the decisions in one module is probably not the answer to good decision-hiding.
      7. Tombstone for prev point: On the other hand, if decisions are related, then they should be in one place.
    2. Second option:
      • Decisions wrt how the log is read during recovery - workR (also knows how to read the opcode, but nothing more).
      • Knowledge about format of log entries - work1 & work2
      • Decision about when to write to log - work1 & work2
      • Decisions wrt implementation of the function (in all the cases) - work1 & work2.
      • Problem: The work seems to be split flow-wise, not major decision wise.
  • No labels