Re: Random namespace pruning

[cjl@ai.mit.edu (Chris Lindblad)]

    Date: Fri 6 Apr 90 07:39:53-CDT
    From: AI.LOEFFLER@mcc.com (David D. Loeffler)

    Thanks for the input.  I have a few other questions and comments.
    1.  What happens if you turn off versions when the machine on the net reboot.
	I thought there was a timestamp cached in the world and the lispm checks
	this with a nameserver.  If the number is lower than the lastest one but
	still in the range then the server sends that machine the updated inform-
	ation between the two timestamps.  If the lispm's timestamp is too old and
	not on the server any more then the lispm reloads the namespace.  Is the
	model of operation correct?  If it is then does it mean that turning off
	the changes file will force all machines to reload the namespace at
	boot time? 

Yes, your analysis is correct.  For the most part, clients will ask the server
for a more information when they boot if you have no changes file, but we have
found this to be no big deal compared to the problems we were having with
changes files.  After world loads get a couple months old, they ask a lot
anyway.

		   (or validation time - we have ours check once a day).

We have also found that just setting neti:*validate-once-per-boot* to NIL is
sufficient to keep the namespace information reasonably consistent on client
machines that don't get booted often.

    2.  I have now rebooted my isolated machine about 6 times and reloaded the 
	namespace several times.  I now have what I believe to be a consistent
	set of 5 namespaces that all run on one machine.  There seems to be a
	few things I should say about what I have learned for other people wanting
	to create more than one namespace on a machine.
	a.  After logging in I do a (net:set-site :my-first-namespace) and it
	    does the usual prompt for host and location.  The host is "local" for
	    me so I just do a <return> but our location is different than the default.
	    we keep our namespace files in >sys>site>namespace> instead of >sys>site>.
	    Our users edit files in >sys>site> and we found it was easier to care
	    for the namespace if we keep the files in a separate directory.  So,
	    for the location prompt I just have to type in "namespace>" and it is
	    merged correctly into the default pathname.

We keep our namespace files in >namespace> for similar reasons.  

	b.  The search list is each namespace object so I get prompted for the 
	    server and location of the MUMBLE-namespace.text files.  Again, this
	    is host local (<return>) and directory "namespace>".  However, this just
	    creates an empty shell for each of these namespaces.  The net:set-site
	    function continues to load all the files for :my-first-namespace and
	    I get warning for objects referenced in it to the other namespaces.

Once again, we never build namespace server worlds on a primary namespace
server, and instead use some client machine and use this form (as seen in an
earlier message) to load the namespace information:

  (let ((neti:*local-host-is-default-secondary-namespace-server* t))
    (neti:keeping-namespace-server
      (neti:with-fixups
	(loop for namespace in neti:*namespace-search-list*
	      do (send namespace :compute-local-server-type)
		 (send namespace :set-unloaded "Building NameServer Worlds")
		 (send namespace :get-latest-timestamp))))))

This doesn't get confused like it does on the server.

	c.  I then run a form to map over all the namespaces and check their validity.
	    (dolist (namespace '(:my-first-namespace :my-second-namespace ...))
	      (send (net:find-object-named :namespace namespace) :check-validity nil t))
	    This forces each of the namespaces not already loaded to load.
	    [it could be that Chris's form would do the same - ie, to map over the 
	    namespace objects in neti:*namespace-search-list* and force them to
	    unload and then ask for the latest timestamp. - I am not sure if
	    this is exactly equivalent but may give the same result in this case]

They are if the namespace search list for the local namespace includes all the
namespaces to be served by the server machine.

	d.  On network objects I created a nickname on all but the ones in :my-first-namespace
	    where the nickname is MY-FIRST-NAMESPACE|CHAOS for chaos net and likewise
	    for INTERNET.

	e.  In all the other MUMBLE-namespace.text files I made sure that the file 
	    references where of the form MY-FIRST-NAMESPACE|THE-NAMESPACE-HOST:>mumble.text
	    where THE-NAMESPACE-HOST is defined in MY-FIRST-NAMESPACE and not in the 
	    other namespaces.  The search list in each namespace will let this host
	    be found evenly but I wanted to be sure to enforce that this host is
	    in MY-FIRST-NAMESPACE.  Similarly for all host references to the
	    primary namespace server.
    3.  I would like to know how the pruning operation works when you build a new
	world on the server.  My experience is that the first changes file written
	after boot has all changes before the timestamp as of the save deleted.  
	The timestamps are still there but with empty entries - (it has been a while
	since we did this so my memory may be off).  This cause problems for machines
	that have older worlds.  I would like to have the server not reap the
	changes file or maybe I will take Chris's suggestion and just get rid
	of the changes file - on our machine this takes about 35+ blocks every
	time it is written.  If the changes file is not included in the mumble-namespace.text
	file then is there still an in core image of the changes still kept or
	is it set to nil?  
			   
If there is no changes file, there is in-core changes list.

			   The reason I ask is that I can usually spot a problem
	with the namespace by seeing the changes file's size decrease (usually from
	about 35 blocks to 5 blocks).  I would like to know if there are any utilities 
	I can run on the server machine that would check the health of the namespace.
	When our changes file drops in size I would have to hand edit it and then
	reboot the machine.  The reason for this is that the incore image of the changes
	is corrupted and other lispms get incorrect information when they boot or check
	on some object.  If I did not fix the problem quickly I have users editing 
	namespace objects to "fix" things they though were there but that someone must
	have deleted or changed on them.  

The form above also can be used to check namespace consistency without
rebooting the namespace server.  You just run it on a client and see what
happens.  It will fail appropriatly if the server has bad information.  I
don't know how to check for bad changes files.

If you made a change to a namespace object file and you want the change to get
propagated, making an entry in the changes file if you are using changes files
and bumping the timestamp, you can use the function
neti:read-object-file-and-update on your namespace server.

You can force a server to reload a namespace from its namespace files (but not
bumping its timestamp) running this form on your namespace server:

(let ((ns (neti:find-namespace-named "YOUR-NAMESPACE")))
  (send ns :set-unloaded "Reloading")
  (send namespace :get-latest-timestamp))

					  What happens when you delete the changes
	file when machines with older worlds boot?

Nothing bad.