Scott wrote: >On Thu, 2008-12-04 at 13:51 -0500, Raymond Dans wrote: >> In resolving XECS-1955, I've implemented it in the following manner >> but have discovered other possible problems which need to be >discussed >> to see if it is intended operation or if some other fixes >need to be done. >> >> The solution that I coded to verify IMDB dependencies for Processes >> was to check for the existence of the particular table in the >> database. If the table doesn't exist, then the resource is not >> satisfied and the process will be blocked from starting. If >the table >> exists (regardless of whether or not there are records in it - I >> assume some tables could be empty) then the resource requirement is >> satisfied and the startup procedure can continue. >> >> With this implementation, I noticed that a few of the IMDB >tables are >> not created/replicated. Two tables that are currently not >created by >> default are "caller-alias" and "userlocation". >> Should "caller-alias" and "userlocation" tables be replicated (by >> SipXConfig I assume during a replication) even if there are >no records >> to put in them? If they're not to be created, then the process >> definition files for SipXproxy and SipRegistrar will have to be >> changed to not rely on them as IMDB Resources. > >The idea is to require that a table be valid if it is required >(note that any resource can have a "required='false'" >attribute, which makes it optional, meaning that the process >is allowed to start without it). > >It's likely that those two tables are not currently replicated >by sipXconfig unless someone has used those features >(caller-id aliasing and location-sensitive routing respectively). > >> SipXSupervisor on startup preloads (which by default, causes them to >> be created if they don't exist already) a list of IMDB databases in >> order to ensure that there is always at least one user of the >> database. This will always ensure that the tables stay in >memory. The >> list of tables that are preloaded are: >> >> 1. Credential >> 2. Subscription >> 3. Registration >> 4. HuntGroup >> 5. Permission >> 6. Extension >> 7. Alias > >My intent here was that it will attempt to preload (and keep >open) all databases that are required by any local service, >and only those... it sounds like there is some old code left >that has a different idea. > >> I have a couple of questions about this. First of all, should >> Supervisor be doing this anymore or should the table get >loaded during >> the IMDB process resource check if and only if the table exists? If >> it doesn't exist, then all processes requiring it will be blocked >> until SipXConfig replicates them. Secondly if Supervisor >must continue >> to preload these tables, should it not preload all tables (i.e. >> including "caller-alias" and "userlocation"? Thirdly, if Supervisor >> preloads all tables, then why would we do an IMDB resource check >> anymore since all tables will always be created? > >I think that rule we want is that a table "exists" even if >empty, but only if there was a legitimate xml file for it to >load at startup time (meaning that it had been replicated at >least once in the past). >
I'm a little confused but lets see if I understand what you're saying: 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". 2. SipxSupervisor mainline should NOT preload any IMDB tables so this call should be removed. 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. 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. If the table does exist, there are no records in it and there is NO xml file then return what (satisfied or not)? If the table does exist and there are records in it and simply return that the resource WAS satisfied. Does this essentially summarize the operation you're expecting? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
