[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Random namespace pruning
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
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
(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))
(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
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?