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 2 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 processed - workR.
      2. Decisions wrt how logging is done (what to write / when to write to log) - work2
      3. Decisions wrt implementation of the function (in all the cases) - work2.
      4. Problem: work1 doesn't seem to hide any decision
      5. Problem: Putting all the decisions in one module is probably not the answer to good decision-hiding.
    2. Second option:
      1. Decisions wrt how the log is processed - workR.
      2. Decisions wrt how logging is done (what to write / when to write to log) - work1 & work2
      3. Decisions wrt implementation of the function (in all the cases) - work1 & work2.
      4. Problem: The work seems to be split flow-wise, not major decision wise.
  • No labels