-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of George Niculae Sent: Wednesday, March 03, 2010 5:51 PM To: [email protected]; Mossman, Paul AVAYA (CAR:9D30) Subject: Re: [sipX-dev] sipXconfig replication rules
--- On Wed, 3/3/10, Paul Mossman <[email protected]> wrote: > > Since I've seen some issues raised due to replication > trigger > > and some fixes that broke other replication > functionality - > > Yes, I've noticed that this has been a problem area. > > > > A first step in this direction could be documenting sipXconfig > > replication trigger mechanism that we > already have > > in place (useful even without considering the event > engine approach) > > Agreed, can you raise a Task JIRA? It would be great to have these > triggers captured. I've raised http://track.sipfoundry.org/browse/XX-7834 to track this. > > As for what to implement... There have been some discussions about > how to generalize replication. One goal would be to eliminate the > need to trigger service restarts at all, but that's a long way off. > > Anything done for the interim would need to be clearly worth the > effort and risk. What kinds of effort would this be? > Quite risky for 4.2 ... > A good point to start is to try to move all the replication logic across > config code inside ReplicationTrigger (and to make all of them event driven - > > both dao & application events). Next step would be to create a declarative > approach for this logic - if someone wants to add new replication logic to be > > able to do this by adding a rule in an xml file (or reusing an existing > one). > Such rule could be (at a first thought): <rule> <name>activateNatTraversal</name> <entity> <class>org.sipfoundry.sipxconfig.admin.commserver.Location</class> </entity> <onSave> <replicate>sipxRelayService</replicate> <restart>sipxProxyService, sipxBridgeService</restart> </onSave> </rule> > Then if we plan to remove service restart we will only have to edit this file. It is an great idea! In this way, for applications, to define the files needed to be replicated and what service(s) should be restarted is just a matter of editing xml without messing around the replication code all over the places. Huijun _______________________________________________ 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/
