-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 5, 2008, at 9:50 PM, A.M. Kuchling wrote:
On Tue, Aug 05, 2008 at 09:13:07PM -0400, Barry Warsaw wrote:
I wonder if the list cache is still worth it? I've run into trouble
with it in the recent past and I suspect that whatever benefits we
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
Mark Sapiro writes:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 5, 2008, at 7:34 PM, Mark Sapiro wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 5, 2008, at 9:08 PM, Stephen J. Turnbull wrote:
Mark Sapiro writes:
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
On Tue, Aug 05, 2008 at 09:13:07PM -0400, Barry Warsaw wrote:
I wonder if the list cache is still worth it? I've run into trouble
with it in the recent past and I suspect that whatever benefits we got
from it in ancient times, may not be so relevant today. My first
I expect cPickle or
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
