[Mailman-Developers] [Mailman-Users] Subscribers suddenly"disappear"

Mark Sapiro mark at msapiro.net
Wed Aug 6 01:34:24 CEST 2008

Max Lanfranconi wrote:

>I tried the "sleep" approach as well. But then I thought that it was not 
>I am setting a relatively high number of mailing list that will receive 
>asynchronous "subscribe" requests via web and/or shell API.
>It would be simply not possible to prevent bug this from happening as 
>the chance of two "subscribe" being processsed almost simultaneously are 
>not that small...
>I also vote for some kind of timing/lock issue.

Based on my running of the test script (see


I think I see the problem. It is related to qrunner list caching and
the fact the there is insufficient precision in the list instance's

The scenario is the following

1) add_member saves the list with the first member.
2) VirginRunner gets there first, instantiates and caches the list.
   It then locks the list, processes the welcome and saves and unlocks
   the list.
3) add_member gets the lock, adds the second member and saves the list.
4) Virgin runner gets the second welcome. The list is cached, so it
   uses the cached instance. It then locks the list which ultimately
   calls MailList.__load() to refresh the list data, but __load()

            mtime = os.path.getmtime(dbfile)
            if mtime <= self.__timestamp:
                # File is not newer
                return None, None

   The problem is os.path.getmtime() returns a time in seconds so if
   we are still in the same second as step 2), we don't refresh the

Thank you very much Max for providing a script to reproduce the problem.

I'm not sure of the best solution. I'm leaning towards dropping the
__timestamp test or perhaps replacing it with a file size test, but
that too may be unreliable.

Other thoughts?

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Developers mailing list