axial recently hit a major milestone with the release of ams (axial messaging service). ams provides users with an end-to-end email solution (much like google’s gmail) that seamlessly integrates with their experience on axial (much like linkedin’s inmail). of all the issues that arose while developing ams, none were as simple and destructive as the one presented below. our solution was as simple and beautiful as the problem itself; and that… is worth writing about my friends.
Consider the case where lisa@gmail.com sends an email to two Axial members, Scuba and Doug. The SMTP envelope might look something like this:
From: lisa@gmail.comTo: scuba@mail.axial.net, doug@mail.axial.netSubject: Our next meetingMessage-ID: <123-abc@mail.google.com>Hey guys! Shall we meet tomorrow at 2 PM?
We use Postfix as an MTA, which means Postfix is responsible for receiving the message and invoking the AMS inbound processor as a maildrop_command. We’ve configured Postfix to deliver each message once per recipient, with the philosophy that failure to deliver to scuba@mail.axial.net should not prevent delivery to doug@mail.axial.net. This means the AMS inbound processor will be invoked twice, once with Delivered-To: scuba@mail.axial.net and another with Delivered-To: doug@mail.axial.net. The following diagram shows Postfix delivering to AMS once per recipient:
The steps for processing an inbound email look something like:
- decode the message
- look at the SMTP headers to see who the email is From and Delivered-To
- record the email in our relational DB
- store the email in the corresponding IMAP mailboxes
The last two steps involve storing and retrieving data. If you’ve ever dealt with two concurrent processes manipulating the same data at once, then you’re probably familiar with the need for inter-process synchronization. To illustrate this, the following diagram shows both processes appending to Lisa’s sent mailbox at once:
The arrows are red because there is a high chance the message gets appended to Lisa’s sent mailbox not once but twice. Although each process first checks to see if the message is already in Lisa’s sent mailbox, there is a chance they both check at the same time, in which case they both end up appending.
We simply need to ensure only one message is processed at a time. Afile system lock won’t do the trick given messages can be processed on different servers and each has its own file system. However, given all of our servers reference the same dedicated SQL server, can we somehow use that as a distributed locking mechanism? Yes! With a named lock, of course!
Remember this is still a single message with a unique Message-ID (in this case ). If we use the Message-ID as the name of our lock, we can use the following logic to get the mutual exclusion we’ve been longing for:
- Get the Message-ID from the SMTP header
- Attempt to obtain a lock whose name is
- If we CAN get the lock then continue processing the inbound email and release the lock when done.
- If we CANNOT get the lock then immediately return 75 (Temporary Failure) to Postfix. Postfix will retry shortly.
With the logic above we can guarantee each message will be processed sequentially. Specifics for using named locks in both MySQL and Postgres can be found below.
Named Locks with MySQL
GET_LOCK(‘’, 10)
Attempt to get the named lock, waiting up to 10 seconds. Return 1 if lock was obtained or 0 if not obtained.
RELEASE_LOCK(‘’)
Release the named lock. Return 1 if lock was released, 0 if lock was obtained by another thread or NULL if lock does not exist
Named Locks with Postgres
It just so happens that we recently switched from MySQL to Postgres. When migrating the locking mechanism above we learned Postgres providesadvisory locks in manyflavors. The big differences are:
- Rather than taking a string, Postfix takes either one 64-bit key or two 32-bit keys as a name for the lock.
- Postgres does not allow a timeout to be specified. This makes sense for us because the 10 seconds above is extremely arbitrary.
We went with pg_try_advisory_xact_lock, which obtains an exclusive transaction level lock if available. Because this lock is at the transaction level it will automatically be released at the end of the transaction and cannot be released explicitly. This has a big advantage over the MySQL implementation, where cautious exception handling was required in order to ensure the lock is always released.
Thanks to:
- Ben “Hurricane” Holzman – for pointing out that MySQL supports named locks
- Jon “Inklesspen” Rosebaugh – for migrating the use of named locks to Postgres
