Changes between Version 6 and Version 7 of BluePrint/Messaging/Outbound


Ignore:
Timestamp:
09/21/12 09:17:43 (9 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Messaging/Outbound

    v6 v7  
    1919(Dominic points out that if each outbound send processes the entire queue including retries, then causing outbound sends could be used as a DoS attack. That works especially "well" if the sends are sure to fail and become retries.)
    2020
     21Other issues we want to deal with:
     22* Make sure queue runs do not overlap.
     23* Must make sure that inserts while the queue is being processed are (thread) safe.
     24
    2125=== Options ===
    22 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. Some options:
    23 * 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-options:
     26Given 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:
     27* 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:
    2428  * Launch the new message queue asynchronously when each new message is posted. Here, there would be a periodic task just for the retry queue.
    2529  * Defer new message sends to a periodic job that runs sufficiently frequently to not cause user annoyance. Here, there would be periodic tasks for both new and retry messages.
    2630* Mark retries and add a parameter that specifies whether retries should be processed on a given run. This requires a change to the queuing mechanism, and although retries would not be attempted during a new message run, they would still have to be iterated over.
    2731
    28 Make sure queue runs do not overlap.
    29 Must make sure that inserts while the queue is being processed are (thread) safe.
     32
    3033
    3134== Email Error Handling ==