More mupdate questions.

[Dave McMurtrie]

Looking further into mupdate this morning (see my earlier message
today), I've discovered something else that looks like an issue.

It looks like a good deal of the calling code that knows about mupdate
relies on basic logic like:

- do a local database lookup

- if the mailbox we're looking for doesn't exist, call kick_mupdate() to
ensure that our local database is fresh, then do the local database
lookup again.

It appears that the thought behind kick_mupdate() is that it was written
to exploit the fact that mupdate will not answer slave requests (on the
local unix socket) while a sync operation is in process.  I notice one
fundamental problem with this, and one area for improvement.

The fundamental problem is that kick_mupdate() returns void.  If a
mupdate slave is not currently listening on its local AF_UNIX socket
(like when it disconnects because it loses contact with the mupdate
master) kick_mupdate() will attempt to connect, fail, log an error and
return.  Most of the calling code I looked at assumes that if
kick_mupdate() returns, the local database is current.  In this case,
that may or may not be true.  At the very least, I think kick_mupdate()
needs to be updated to be able to return a status so any calling code
can make a more informed decision about what to do.

The area for improvement is that kick_mupdate() never times out its
read() from mupdate's local unix socket.  Wouldn't it be a good idea to
wrap this read() in an alarm() call and return failure?

Before I start working on a patch, can someone who is familiar with this
code let me know if I'm way off base or not?

Thanks,

Dave
-- 
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services