On Tue, May 17, 2011 at 7:51 PM, Cristi Starasciuc <[email protected]>wrote:
> On 05/06/2011 07:20 PM, Mircea Carasel wrote: > > Hi, > > I am posting a functional patch for XX-9554. GUI is not polished, but > looks stable to me and shows accurate results > Feel free to comment the implementation. It took longer than expected to > bring it in this form, but I was impeded by many other tasks. > > George, Cristi, Douglas - your feedback will be appreciated (if anyone of > you has time to have a look) > > Here is the patch description: > > -Created cache to hold successful/failed replications > (FailedReplicationState.java) > AuditLogContext is responsible with maintaining this cahce > -created worker in AuditLogContext to push replication finished event > > -saved replication in DB, created two tables linked with location table > 1-m > to hold successful/failed replicaitons > location_success_replications,location_failed_replications > > Mongo replication is saved in one single entry in DB named: Database > generation > Other services configuration files, and others names are saved > Overall there are around 50 records for each location > > UI report, click on server show replication result: > send profiles shows replication progress > otherwise we show last replication result from db > the cache is filled with last replication result during firstrun - in this > way any ocasional replication fits correcly in chace > this cache show always the current result of replications > -save in locaion table data of last replication and status: > CONFIGURED -replication successful > CONFIGURATION_ERROR - something failed > > Thank you > Mircea > > > _______________________________________________ > sipx-dev mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > Mircea, all > > attached is the rebased patch. > > I looked at the patch it looks good, seems like you're on the right track > with this. Here's my input: > > I can't see "In progress" state. If I hit Send profiles, the status does > not change. I think it should be "In progress". > I would include "Last attempt" field in Replication details page (See state > link) and not in locations table. Can't see much use for it there. > Yes, correct - we should add this new state > And also, I would put instead of a timestamp a start and end time. (liek in > Job status, but global) > That's a bit hard to accomplish since some files are replicated asynchronously. One way would be to compare the results saved after first-run-task, but send profiles does not replicate the same set of files as first-run-task. sipxconfig-report for instance is replicated only at first-run task or when a location is updated. Maybe it would be better for send profiles to replicate everything, as first-run-task does > > If I stop Mongo and go to a user, make a change and hit Apply, I get a > "Replication error" in users' page. Then, if I go to server's page, i will > see the server is in Configuration error state. Which is not quite > correct, IMO, since a mongo error would not render the PG and Mongo > databases out of sync. So there's nothing wrong with the configuration of > the server. Sure, it will not work as expected, since Mongo being down it > means chaos to the system. > If I start Mongo, and go to the user, make the changes and then save, the > server remains in Configuration error status. > > the only way to bring it to Configured state is to send profiles, which in > the described case is not necessary. > > I'd propose that single Mongo replication errors would not produce > "Configuration error" status; I'm open to discussions, of course. > we can put a dedicated state to reflect that the only problem is Mongo is down > > With files is a bit different, a failed file generation can render the file > not usable, it may have 0 length, or be a malformed xml - that definitely is > a misconfiguration that may have an impact on certain sipXecs services. > > Question: I'm wondering if we could "remember" the failed jobs and have the > possibility to "retry" them? > failed jobs are saved in DB, There are two tables there: location_failed_replications and location_success_replications where failed and succesful replicated entity names are saved Mircea > > > Cheers, > Cristi > > _______________________________________________ > 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/
