There are still problems around loading subscription.xml (the most recent issue is http://track.sipfoundry.org/browse/XX-6649 , where it didn't get loaded at all).
An earlier discussion starting at http://list.sipfoundry.org/archive/sipx-dev/msg17145.html is interesting, but I don't think we got to the root of the problem in the commit done in 15104 to fix XECS-2463 (http://track.sipfoundry.org/browse/XX-4765). The root of the problem seems to be that the various DB classes are not true singletons, at least not across processes. We end up with a separate instance (and lock) in each process, so setting mTableLoaded flags (for example) is useless to ensure that the xml file is only loaded once. The only thing which makes the xml file be loaded once (most of the time) is the check on the number of users of the database (pSIPDBManager->getNumDatabaseProcesses(name)); but the constructor fails to load at all if the number of users is not one, and I think that must be happening sometimes on startup (i.e. two processes are starting up at the same time, and both constructors see two users, so don't load). There could also be a problem in writing the file, since the separate lock in each process does not guarantee that one process will not begin to write the file while another is also in the process of writing. There are some other issues: - supervisor does NOT preload the subscription.xml file, because it is always listed as "required=false" in the process def files (this is not a replicated file, and does not always exist). - SubscriptionDB::load() will return false if the file does not exist (this should return success). QUESTION: should this be a special case for subscription.xml, or does it apply to some of the other files as well? (specifically registration.xml) - SIPDBManager::preloadDatabaseTable does not even have a case for the SUBSCRIPTION table - initializing mTableLoaded to true seems clearly wrong (how can it be loaded if nothing has loaded it?). Also, it's a member variable (not static), and it is inialized in each process! Loading the file in one process isn't visible to other processes (which is why Dale found he had to force it to true, but that isn't correct...) - I can't reproduce it, but I think the "not loaded" case occurs when getNumDatabaseProcesses returns more than one user (and since we initialized mTableLoaded to true, we don't load it unless users==1) It seems to me that we need the SubscriptonDB class and probably all the DB classes to be true cross-process singletons so that there is a single lock guarding the file and we can guarantee that only one process will load the file into the IMDB. Failing this (or maybe as well as this), to continue the current workaround of having the supervisor preload everything, the first few changes listed above (allow the file not to exist, and make the subscription IMDB a required resource) will mask the startup problem, but still leave a possible file-mangling problem if two processes decide to write the file at the same time. Comments? Carolyn
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
