On Wed, Apr 8, 2015 at 1:03 PM, Mark Michelson <reviewbo...@asterisk.org> wrote:
Before I repost the AstDB Clustering review from Review Board onto Gerrit, I wanted to address Mark's concerns below. Depending on what people think, it may be worth just shelving the idea. > > The only things I can think of that are issues here are based on theoretical > usage of shared DB families, especially global ones. > > Say that someone is sharing /foo/key between Asterisk 1 and Asterisk 2. A > user on Asterisk 1 sets /foo/key = bar at the same time that a user on > Asterisk 2 sets /foo/key = baz. What may happen is that the local Asterisk > boxes will set the values locally and then publish the updated values > near-simultaneously to the other Asterisk box. The result may be that they > both have /foo/key = bar, they both might have /foo/key = baz, or Asterisk 1 > may end up with /foo/key = baz and Asterisk 2 ends up with /foo/key = bar. > Essentially, there is nothing in place to guarantee the synchronization of > globally shared values. That is correct. There is no implicit synchronization. Using a 'global shared family' implies some level of knowledge about how the keys are used on the respective systems. Where this is useful is places like registration, where you "know" that the devices registering to a cluster of Asterisk servers are all unique, but you want the knowledge of the registration to be shared globally. In that respect, this is very much like clustering of MWI. There is no aggregation of MWI IDs between Asterisk instances, nor is there synchronization of values. If someone configures identical mailbox IDs on two Asterisk systems and updates the mailbox state to different states on different servers, a discontinuity will occur. > So what's the best way to deal with this? I can think of several answers: > * The AstDB may not be the right tool for this use case and you should be > using a key-value store that is built for this instead. Possibly. In that case, you'd simply have the AstDB pass through to some other mechanism (redis/RabbitMQ/etc.) In the long run this may be better. It would be interesting to have the AstDB act as a facade on top of some other technology, defaulting to SQLite3. > * You may be able to satisfy your use case with unique shared keys instead of > global shared keys. I think they are separate use cases. If you don't know whether or not you will have collisions, unique shared keys is clearly the answer, but you have to aggregate the duplicates yourself. If you have global keys, you're either not caring about the synchronization, or you 'know' that all keys will be unique across all Asterisk instances. > * We may want to make global shared keys one-way. In other words, there is an > "owner" of the key and "listeners" for changes in the key's value. Listeners > on a global shared key cannot update their local DB with new values; only the > owner can push new values to it. Listeners on a global shared key cannot > share the value with other listeners; only owners may push changes to > listeners. I think if we went down that road, I'd personally rather scrap the change and have the AstDB sit in front of other technologies. > While I'm thinking about it, there's also the possibility that the underlying > AstDB implementation could be replaced with a key-value store that has the > concept of replication built into it. If that were done, then presumably, > there would be no need to involve Stasis or SIP PUBLISH in the process of > sharing values between Asterisk boxes. > Yup. SO! The question is: is this change worth having, or should it be scrapped in favour of some alternate approach that makes use of other technology? My feelings won't be hurt if the answer is "ditch it and do something else" - this was a fun piece of code to right on some plane flights. On the other hand, I don't have any real interest in writing an alternative approach, so if the expectation is that an AstDB wrapper around RabbitMQ or Redis will magically appear if I hit the delete key, that expectation is likely to be wrong. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev