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

[Massimo Lanfranconi]

Mark,

I am more than willing to try any workaround as this bug is currently a 
showstopper for my project.
I am not very versed in mailman internals, so I need some guidance here.

Do you recommend I try getting rid of  the __timestamp test and give it 
a try ?

If that is you suggestion, may I ask what was the original purpose of 
that test ?

Thanks again for your help in solving this.

Regards,

Max

Mark Sapiro wrote:
> Max Lanfranconi wrote:
>
>   
>> I tried the "sleep" approach as well. But then I thought that it was not 
>> viable.
>> 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
> <http://mail.python.org/pipermail/mailman-users/2008-August/062885.html>,
> with
>
> LIST_LOCK_DEBUGGING = True
>
> 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
> __timestamp
>
> 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()
>    does
>
>             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
>    list.
>
> 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?
>
>   


-- 
-- 
<http://jcp.org> 	* Max Lanfranconi *
JCP Program Management Office
Marketing Manager

Phone +1 408 404 6893
Mobile +1 408 505 1020
Email max at jcp.org