Changes between Version 9 and Version 10 of BluePrint/Messaging/Outbound

09/21/12 12:43:25 (11 years ago)
Pat Tressel



  • BluePrint/Messaging/Outbound

    v9 v10  
    44== Outbound Queue Performance ==
    56=== Issues ===
    68We would like to send out new messages in a timely manner, without doing time-consuming sends in request context where they will slow down response to the user, but also handle retrying failed messages and avoid unnecessary overhead.
    2527=== Options ===
    2629Given that we want to queue up new messages rather than attempt a direct send before queuing (to avoid slow request response), and given that retries are a significant potential overhead, one option is to separate new message processing from retries. Sub-options:
    2730* Use separate queues for new messages versus retries. After a run of the new message queue, each message will either be sent or will fail and be inserted in the retry queue, so -- except for messages inserted during the run -- the new message queue will be empty. This does not require a change to the queuing mechanism. Sub-sub-options:
    4346  * Failures (immediately permanent fails and max retries exceeded)
    45 * Let site choose whether to start a new message queue processing run when a new message is posted or use a periodic task for new messages, and periodic task frequencies.
     48* Let site choose periodic task frequencies, and whether to start an async new message processing run when a new message is posted or use a periodic task for new messages.
    47 * Include advice in the user guidelines for async vs. periodic new message processing, and for setting periodic task frequencies, based on the site's message behavior.
     50* Include advice in the user guidelines for the above choices, based on the site's messaging behavior.
    4952* Add logging of errors. Detect obvious misconfiguration and object strenuously.
    5760== Email Error Handling ==
    5862Web2py's Mail.send raises exceptions, contradicting its docstring. In particular, a common configuration error, failing to edit the example email sender, will cause a ticket when a user attempts to register. (Registration includes an email send even if no verification or approval is needed, as the user will get a welcome message in that case.) Since this is not a user error, but rather a misconfiguration that the site admin needs to deal with, it should not block registration nor show an error to the user. (See also ticket #439 -- we currently delete the user's temporary registration if there is an email error, but don't report anything to the site admin.)