[MUD-Dev] Virtual machine design

[Schubert]

From: Mik Clarke [mailto:mikclrk at ibm.net]

> Eli Stevens (KiZurich) wrote:
> 
> > I was wondering what the general consensus on 
>> "not having to reboot" meant
> > to the list.  Obviously, if the power goes off to the 
>> system the MUD is on, the MUD will have to reboot. 
>> What must be supported on-the-fly for a MUD to
> > be considered rebootless?
> 
> I work on an approach that considers the frequency 
> with which you think the data will need to be changed.  
> Rebooting every hour is not acceptable.  Rebooting
> once a day is not good.  Rebooting once a week 
> (assuming the mud can stay up that long) is 
> acceptable.  Rebooting never would be nice, but 
> it needs more code than a mud which is expected 
> to be rebooted once a week.

In my mind, the key is not to avoid machine reboot as 
much as code reboot - i.e. shut down the server app 
and start it again.  Meridian 59 had a nice system where
compiled scripts were put into a special directory, 
and a 'reload' command would replace existing scripts
with those in this directory.  This drastically reduced 
development time and headaches.

> Comercial systems (non-Mud) will generally have 
> a 1 or 2 hour  'service slot' during each week when 
> their owners can changed things and reboot them 
>(or even reboot the server).  More critical servers 
> (production line control, flight
> control) will have much tighter windows, generally 
> no more than a few hours on 2 or 3 days each year 
> (and planned well in advance).  These are 
> planned outages.Some people spend a LOT of 
> money to try to avoid and/or minimise unplanned
> outages (due to hardware/software or site 
> problems).  For a MUD, even a
> comercial one, the benefit generally isn't worth the effort.

Meridian 59 had downtime once a week.  Code updates
were relatively rare (and as noted before, could be done
without reboot in the case of emergency), but was done
largely to free system resources.  It also gave us a time
when everyone was offline so we could do fixes that might
require database repair or something else equally icky.
Fortunately, we rarely needed this time, but we were 
glad we had it the one or two times we did. We did it 
Tuesday, so if something went horribly amiss,
we'd have Wednesday, Thursday and Friday to fix it
before the weekend crowds came.



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev