On Fri, 2008-12-05 at 12:36 -0500, Raymond Dans wrote:
>
> 1. The owners of the Processes that have IMDB tables like "caller-alias"
> and "userlocation" need to modify their process definition files to mark
> (using the attribute required) these tables as "required=false".
Correct. caller-alias should be declared by sipXproxy, and userlocation
by sipXregistrar, if I'm not mistaken (technically, both of these are
used by plugins loaded by those components, but we have not yet dealt
with that subtlety in our process management scheme, and won't for this
release).
> 2. SipxSupervisor mainline should NOT preload any IMDB tables so this
> call should be removed.
It should not preload any explicitly, yes... but in
sipXsupervisor/src/ImdbResource.cpp see:
bool ImdbResource::isReadyToStart(UtlString& missingResource)
{
OsLock mutex(mLock);
if (NULL == mDatabase)
{
mDatabase = SIPDBManager::getInstance()->getDatabase(*this);
}
bool rc = (NULL != mDatabase);
if (!rc)
{
missingResource = "";
appendDescription(missingResource);
}
return rc;
}
... when a process tests to see if an imdb resource is ready, the check
loads it as a side effect and stores the db handle in the resource. So
any imdb that is needed by any process will always be preloaded, and
since the sipXsupervisor holds that handle until it shuts down, the
database should remain loaded (which was the original purpose of the
preloading mechanism). The SIPDBManager::preloadAllDatabases method is
no longer needed (it should just be removed from SIPDBManager
altogether).
> 3. When the SipxSupervisor Process Manager asks to verify an IMDB
> resource, the following should occur:
>
> Check to see if the table exists:
>
> If it does NOT exist yet, see if there is an xml file for this table
> and if so load it. If no xml file exists then the resource is NOT
> satisfied and will return indicating this.
that's correct (verify that this is the behavior of the getInstance
through the SIPDBManager for each)
> If the table does exist, there are no records in it and an xml file
> exists, load it and return that the resource WAS satisfied.
that should be the same case as the above - that is, the sipXsupervisor
can't tell the difference because it's all handled in SIPDBManager.
> If the table does exist, there are no records in it and there is NO
> xml file then return what (satisfied or not)?
That case doesn't make sense because the xml file is _always_ created
_from_ the in-memory data as a side effect of that data being written by
sipXconfig through the replication mechanism, so you can't have (and
don't need to check for) the cases in which "the table does exist and
there is NO xml file".
> If the table does exist and there are records in it and simply return
> that the resource WAS satisfied.
Right, but again from the point of view of sipXsupervisor you really
can't tell the difference between that and the first or second cases.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
