The mailing list for listmasters using Sympa

[John Dalbec <address@concealed>]

Olivier Salaun - CRU wrote:
> John Dalbec wrote:
>
> > I have Sympa 3.3.3 in production currently.  I was trying to send 
> > e-mails to several groups of people by creating a single list and 
> > updating the SQL query for each group.  However, when I updated the 
> > SQL query, sympa kept using cached data for the mailing list.  
>
>
> You're right, we're lacking a members cache update after data_source 
> related parameters were changed. It could either be performed by 
> wwsympa.fcgi itself (if the job does not take too long) or ordered to 
> the task_manager.

After any update, wwsympa.fcgi rebuilds its in-memory subscriber list. 
It looks like it also updates subscribers.db at that time.
How does sympa.pl decide whether it needs to refresh its in-memory list 
of subscribers?  Does it compare timestamps?  Configuration serial 
numbers?  Or do you look at specific parameters in the configuration?

> > I dropped the lookup timeout to 1 second and that seemed to help, but 
> > shouldn't Sympa recognize when the configuration file has been updated 
> > and refresh the in-memory list of addresses?  Does the in-memory list 
> > of addresses have a timestamp?  

After I dropped the timeout to 1 second, I noticed that some subscribers 
were missed entirely.  In some cases they had "email addresses" that 
were clearly invalid, but others had normal-looking email addresses and 
yet no email was sent to them.  Any idea why this might happen?  Is it 
because I changed _load_users_include to maintain the hash tie to 
subscribers.db and some changes were buffered?  Or was it that the list 
configuration changed before sympa finished sending out emails?  Is 
there any way for an end user to determine when it's "safe" to change 
the configuration?

> It would be an interesting information to show on the admin web 
> interface ; please add an entry to the "bug tracking" system about this 
> feature : http://listes.cru.fr/mantis/

That wasn't what I had in mind.  I see you do have a timestamp (plus a 
serial number) in $list->{admin}{update}, so you have enough information 
to detect when the configuration has changed.
Thanks,
John

> > Does 3.4.4.1 fix this? 
>
>
> No this behavior has not changed since Sympa 3.3.3.
> We planned some work related to include2 for Sympa 4.0, including 
> merging 'database' and 'include2' concepts.