Sounds good .. another option might be to be able to trigger a spool to disk manually via admin I/F before a restart .. i.e. go isolated (or whatever it is) and then dump internal to store .. start isolated and then trigger a load ..
actually as I type it sounds a bit painful ;) On Thu, 2012-08-09 at 14:00 +0200, Stipe Tolj wrote: > Am 07.08.2012 23:54, schrieb Alan McNatty: > > On Wed, 2012-08-08 at 09:43 +1200, Alan McNatty wrote: > >> also providing persistence as a default option is also very valuable. > > > > An additional enhancement might be to spool the current in memory hash > > on shut-down and load on start-up. > > correct! This is at least an option to avoid the loose of the temporary > DLR data, while shutting the bearerbox down. > > For "special conditions", like segfaults, we can even do this before the > OS layer forces us to die. I.e. smppbox does this for various file > system stored data. Ensuring we get at least as much as possible saved, > before going to Nirvana. > > Though, not sure if we want this "store at end" and "load at start" to > be default for 'dlr-storage = internal', since it involves huge delays > in start-up time, at least on file systems that handle large amounts of > small files in a lot of directories, i.e. ext3. > > We could "fork" this to a "new" type, keeping the same implementation > files gw/dlr_mem.[ch], but calling it > > dlr-storage = spool-internal > > to indicate that we use the spool, but keep the runtime internal > in-memory. Then we can simply pass a flag to the init function > indicating that we want loading the store and saving at shutdown. > > Stipe >
