> > > > I agree with you, the way it appears to be working doesn't sound very > useful. I'm sure there's no comments explaining why. Does the code > explicitly call out these exceptions, or given the design do you feel > it could be an likely mistake. If you have a few minutes to get to > the bottom of it, it would be greatly appreciated, I certainly have > made assumptions on customer machines that send profiles send all > config info. > I think that the code can be more organized than the way it is now, in this way, duplicate replications can be avoided
I also think that sendProfiles should do exactly the same thing as firstRunTask concerning replications, meaning to replicate all config I made some more analysis and here are my findings: 1. methods that are involved in replications: * initLocation(Location)* -replicates domain-config -replicates supervisor configuration file -replicates alarm server service -generates all data in Mongo *replicateLocation(Location)* -replicates all services config files -re-synch Mongo DB *enforceRole(Location)* -stops all services that are marked to be stopped -launches executor that replicates all services that need to be replicated (services that need to be started, minus the one that are stopped, stopped services don't need to be replicated) initLocations() * * * * * * > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
