On Thu, Sep 3, 2015, at 23:50, Ken Murchison wrote: > On 09/03/2015 08:42 AM, Bron Gondwana wrote: > > IOERROR: failed to create fastmail.com!user.REDACTED.#calendars (Mailbox is > > locked) > > > > We get these occasionally, and I wondered why until just now, when I > > remembered... > > > > The initial CREATE or RENAME lock.. it's a mboxname_lock EXCLUSIVE, and > > it's taken with nowait, and error if exists. It needs to, because the > > source mailbox is locked, and you need to break a lock loop if you issued > > rename A => B and rename B => A in parallel. > > > > So it was assumed as being not a problem, because you'd never try to create > > the same name twice concurrently. The name didn't exist before, so nobody > > will be looking at it. > > > > When I say "it was assumed", I mean that I assumed. In 2009 some time. > > > > But that's not true when you're autocreating the same name when you try to > > read something. Anything. > > > > In fact, the way that the parser works, you wind up doing it for any http > > request. So you get a race between two processes, one loses, logs this. > > > > We should probably fix this :) > > > > Bron. > > > Doesn't the current code check to see if the calendar-home-set mailbox > (and others) exist before trying to CREATE them?
Yeah, but it's racy. If two processes try at the same time, then they'll both go for the exclusive lock with a non-blocking request, and one will miss out. Bron. -- Bron Gondwana br...@fastmail.fm
