Changes between Version 6 and Version 7 of SharedMemoryIPC


Ignore:
Timestamp:
Apr 12, 2013, 7:14:00 AM (5 years ago)
Author:
jinmei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SharedMemoryIPC

    v6 v7  
    267267recovers consistency.
    268268
    269 === 5.6 Full Data Source Reconfiguration ===
    270 
    271 Updating the entire configuration of data sources can be a bit more
    272 tricky.  We'll probably first need to introduce a concept of
    273 generation ID of configuration, which will be managed by the cfgmgr
    274 per module basis.  Processes referring to the configuration of the
    275 same module (like "data_sources") use the generation ID of that
    276 module's configuration so they can determine which version of config
    277 is referred to in case of migration.  On top of this, both the manager
    278 and readers will keep two sets of data source clients (and associated
    279 states), and performs operation for the new version of the set just
    280 like the initial start up, while using the current set.  When
    281 migration is fully completed the old version of the set (and maps)
    282 will be discarded.
    283 
    284 More details will have to be considered, though.  They are still quite
    285 open.
    286 
    287 === 5.7 Rebuild Initial Map File On Demand ===
     269=== 5.6 Rebuild Initial Map File On Demand ===
    288270
    289271The described scenario so far implicitly assumed that the created/existing
     
    295277original master file(s)).
    296278
    297 Details of this are quite open, too.
     279Details of this are quite open.
     280
     281== 6. Full Data Source Reconfiguration ==
     282
     283Updating the entire configuration of data sources will be a bit more
     284tricky.  This is a rough sketch of initial ideas on how it would work.
     285While it looks like workable, more details will probably have to be
     286determined.
     287
     288=== 6.1. Configuration generation IDs ===
     289
     290First, we'll need a concept of generation ID of configuration, which
     291will be managed by the cfgmgr per module basis.  Processes referring
     292to the configuration of the same module (like "data_sources") use the
     293generation ID of that module's configuration so they can determine
     294which version of config is referred to in case of migration.
     295
     296Generation IDs monotonically increase and the latest one will be saved
     297in the configuration DB file.
     298
     299=== 6.2. Memory Manager Behavior ===
     300
     301The Memmgr now manages sets of data source clients and mapped files
     302per generation ID of the "data_sources" configuration.  Memmgr keeps
     303a set of a particular generation ID as long as some reader still uses
     304a memory segment of that generation.
     305
     306segment_info_update and its ack message now contain the corresponding
     307generation ID.
     308
     309mapped file names would now include the generation ID, too, e.g.
     310zone-mapped-in-sqlite3-42.0 where "in" is RR class, "sqlite3" is the
     311data source name, and 42 is the generation ID.
     312
     313When the memmgr receives a configuration update for full data source,
     314it will create a whole new set of data source clients and mapped files
     315(so, during the migration we'll at least maintain 4 mapped files per
     316data source), and then send segment_info_update message to all readers
     317for all mapped segments.  It waits until it gets ack from all
     318outstanding updates.  On completion, the memgmr can be sure all
     319readers now use the new generation of segments, so it can discard
     320any information including mapped segments of older generations.
     321
     322=== 6.3. Reader Behavior ===
     323
     324Likewise, readers maintain sets of data source client lists per
     325generation ID.
     326
     327When a reader receives a configuration update for full data source,
     328it tries to complete all WAITING segments for the corresponding client
     329list, just like the initial setup.  When all segments are set,
     330it swaps the new and old sets, wait until the old one is cleaned up,
     331*then* respond to the latest segment_info_update message (the ordering
     332is important because the memmgr will assume the reader does not use
     333the old generation of segment anymore on receiving the ack).
     334
     335It would be possible that a reader receives a segment_info_update for
     336a generation ID older (smaller) than the generation of its first data
     337source configuration.  It happens if a reader joins the system later
     338than others immediately followed by a configuration update.  the
     339reader would only get the latest generation ID from config manager,
     340while memmgr still doesn't get that generation of config.  In such a
     341case, the reader can simply respond to the update.
     342
     343It would also be possible that a reader receives a segment_info_update
     344for a generation ID newer (larger) than its latest generation.  This
     345means a configuration update has been delivered to memgmr and is also
     346coming to the reader but has not arrived.  In this case, the reader
     347should keep the update message (pending ack) until it gets the
     348corresponding configuration update.  As long as the system is working
     349correctly this event should eventually happen.  At that point the
     350reader can resume handling the saved update message and respond to it.