I understand and like I said, just trying to find a way which doesn't involve rebuilding sipx. I redundancy but I can live with it not being perfect, just enough that users can tolerate the occasional problem. Most important, having multiple locations in case one becomes unavailable, which is why I wondered about being able to sync things up between servers.
In other to have a fully redundant server, those features would have to be built into the server but sometimes, there are things you can get by with, such as simply syncing up regularly. I can't count how many times that's worked just fine and figured there should be a way of accomplishing the same thing in this case. On Tue, 19 Jan 2010 12:46:44 -0500, Dale Worley wrote: > On Tue, 2010-01-19 at 11:09 -0600, [email protected] wrote: > >>>> Might there be some way of having two then, which are kept in sync? >>>> >>> That would be a wonderfully difficult software engineering problem! >>> >> Why is that? >> What about using a shared mapped storage for both sipx instances so >> that each can find vm's. Then, a way of syncing up vm notices on the >> two sipx instances so that if a user logs into either, they can get at >> their vm. >> > And a system of locks so that if one caller is leaving a VM for ext. 123 > using system A, and another caller is leaving a VM for ext. 123 using > system B, neither system corrupts the changes to storage that the other > one is making... > > The problem is one of a fully distributed and redundant database. > > Dale _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
