The mailing list for listmasters using Sympa

[Olivier Salaün - CRU <address@concealed>]

We've got to update the documentation to include the text below (part of the NEWS file) that might provide you with more information about 'include2'.

To answer your questions :
If the datasource is not available, the listmaster is notified ; the current cache is still used.
If the datasource remains unreachable, sympa doesn't cope with the cache reset.

    New 'include2' user_data_source ; should replace 'include'.
    Users cache is stored in the main database instead of using a
    DB_File. Updates of the cache are performed by the task_manager

    * Advantages

            + lower memory usage :
            Sympa processes used to use lots of memory when managing
            big (>200 000) 'include' types of lists. The list of
            subscribers is now stored in the database.

            + updating the cache :
            Cache update is now performed by the task manager. It used to
            be performed by sympa.pl and wwsympa.fcgi.

            + bounces management :
            Because included users now have an entry in subscriber_table,
            their bounces are managed like any other subscribed users

            + user reception options :
            Included users can set their reception mode

    * Subscriber_table changes

        The subscriber_table Db table has 3 new fields :

                  * included_subscriber
                This boolean value tells if the user has been included into
                the list

                * subscribed_subscriber
                This boolean value tells if the user has subscribed to the
                list

                * include_sources_subscriber
                Comma-separated list of include source IDs. It is not
                exploited yet, but could be used to :
                      - set different TTL for each include data_sources
                      - show include sources in the REVIEW pages
                      - tell the user he/she has been included as part
                      of X,Y external datasources

    * Task manager

    New 'sync_include' list task :
    Only one model (ttl) is available. TM checks if the list is
    in 'include2' mode and runs the sync_include. The syn_include()
    does an in-memory comparison of already cache users list and
    included users list ; subscriber_table is then updated.    
    List::delete_user() and List::add_user() have been optimized
    to make sync_include() faster.
    A new task is created based on 'ttl' list parameter.

    New 'purge_user-table' global task :
    Each time a user unsubscribes the user_table had to be cleaned ;
    this was time-consuming. This is now performed periodically
    by the 'purge_user-table' task.


    * Changes of commands behavior

    Reception options
    Included users can now set their reception mode

    Subscription
    Included users can moreover subscribe to the list (if allowed by scenario).
    It allows them to remain in the list though they might no more be included.

    Review (web only)
    Foreach user, tell if he/she is included or subscribed


    * Locking while updating cache

    An exclusive lock is performed by sync_include() to prevent other processes
    from accessing an uncomplete list of users. A shared lock is set in
    List::get_first_user(), then released for the last List::get_next_user().
    File locking is performed on ~sympa/expl/<list>/include.lock file

    * Stats file

    A new value has been added to lists 'stats' file : last_sync
    I is the date (epoch format) of the last include cache update.

    * List configuration edition

    When the list configuration has been changed (from the web), then :
            * if we changed a datasource-related parameter
            => the current 'sync_include' task is removed from the task
            spool, to make cache update happen as soon as possible.

            * if user_data_source changed from 'database' to 'include2'
            => existing subscribers have their 'subscribed_subscriber' DB
            field set to '1'

            * if user_data_source changed from 'include2' to 'database'
            => existing included users are purged from subscriber_table

Anders Lund wrote:

I've had a quick browse through the doc, but I'm unable to find
information about what happens if data source is unavailable when sympa
does a refresh of included members.

If the data source is unavailable:
 * does Sympa use the old cache, and if "yes" for how long?
 * does it send some kind of warning to the Listmaster or log something?
  

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature