On Mon, May 30, 2005, Geo Carncross <[EMAIL PROTECTED]> said:
> If anyone is scared of the token-passing software (implementation) I'm > happy to help out here. It's _really_ not as difficult as it looks: it's > one of those things. If your implementation isn't simple, you probably > messed it up :) > > But note what's hard is getting dbmail to actually follow it. Right now, > APPEND updates the mail store- and it can't do that. Furthermore, the > mail store needs to have it's "active" bit for messages so dbmail won't > touch messages that are (ahem) inactive. This means changes to indexes, > reprofiling this code for various databases, etc. > > I think it's provable that ANY method will require an active bit (either > the database sets it with a trigger or second-agent, or _we_ do using > the token passing protocol), so it might as well be time to start adding > it. > > dbmail TRUNK will simply APPEND with that bit set until we add the > requisite UID generation part. Ok, let's see if this is what you're thinking: DBMail 2.0.x currently inserts a message with ownership set to an internal user, then performs the delivery resolution and uid generation, and copies the message over to any user scheduled to receive it. In a clustered setting, we add one more part to the behind-the-scenes phase: getting a token from the cluster. Once the machine has the token, it can generate uid's for all of the messages it has queued, pass off the token to the next machine, and then deliver all of messages. Each machine would thus queue incoming messages which were otherwise ready for delivery, wait for the token, then deliver them. Database replication would be handled by the database, and would be lockless multimaster because we have already done the work of guaranteeing that uid's won't conflict. As you mention, however, the APPEND command would also have to be rewritten to wait for a token. Is that a problem from a user interactivity perspective? I figure it might sometimes take more than a few seconds to receive a token. Will this cause a problem if the OK response is delayed until a token is received? Also, for the token algorithm, is there a mechanism to ask for the token? In order to prevent token-storming, each machine holds the token until it either 1) processes a queue of messages or 2) waits for a timeout. If you don't have a timeout, then you have tokens flying about eating up all bandwidth and doing nothing. But if there's a machine on the other side of the cluster that has a messages, but the token is several seconds away on the other side of the cluster, perhaps it should be requested for with a packet that flies full speed backwards, telling each machine that it should pass the token forwards ASAP. Right? Aaron
