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 [EMAIL PROTECTED]
_______________________________________________
Mailman-Developers mailing list
[email protected]
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
