> 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. It might be good to make the machine with the token hold onto it until another machine requests it. This way each machine on the cluster will broadcast token requests when it has messages queued for delivery. The machine with the token can just hand off first come first server.. or give it to the machine that has been without the token longest to balance the token load a bit. This should prevent the token from zippin around in circles for no reason. Token by request.
Under the same delivery concept it might be good to have a time to wait threshold for the token so that no one machine can hold onto it for to long. Oops I guess this is what you were talking about below.. didn't finish reading. > 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 > > > > > > > > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
