Changes between Version 14 and Version 15 of BluePrint/Messaging/Outbound


Ignore:
Timestamp:
09/21/12 13:41:03 (9 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Messaging/Outbound

    v14 v15  
    1010Right now, inserting a message in the queue (send_by_pe_id) is unconditionally followed by kicking off the outbound sending task (which runs asynchronously, not in request context). That isn't just making an attempt to send the single new message, but rather processes the entire queue. Messages that are in the queue in order to be retried due to an earlier send failure will be retried along with the one new message.
    1111
    12 To avoid a time hit to users during requests that currently include a message send (currently the known cases are all registration email), we can instead queue up those messages. If we do that, we need to deal with the consequences of sharing the queue between new and retry messages.
     12To avoid a time hit to users during requests that currently include a message send (currently the known cases are all registration email), we can instead -- if msg is enabled -- queue up those messages. If we do that, we need to deal with the consequences of sharing the queue between new and retry messages.
    1313
    1414Consider these cases:
     
    2424* Make sure queue runs do not overlap.
    2525* Must make sure that inserts while the queue is being processed are (thread) safe.
     26* Use logging rather than prints to stderr for error (etc.) messages intended for the site admin. (This is more general than messaging, but we could just start using it and get the pattern down before converting other prints to stderr.)
    2627
    2728=== Options ===
    2829
    29 Given 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:
     30Given that, if msg is enabled, we want to queue up new messages 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:
    3031* 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:
    3132  * Launch the new message queue asynchronously when each new message is posted. Here, there would be a periodic task just for the retry queue.
     
    4041
    4142Initial part:
     43
     44* If msg is enabled, queue up new messages rather than sending them directly.
    4245
    4346* Split outbound processing into three queues:
     
    6366
    6467* Check whether we already prevent overlapping runs. (Note the conditional scheduling I was working on, but that wasn't needed for Ashwyn's GSoC project, did deal with this, so this may be why I thought we might already be handling this.)
     68
     69* Does this deal with the DoS?
    6570
    6671== Email Error Handling ==