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

Timestamp:

09/21/12 09:17:43 (13 years ago)

Author:

Pat Tressel

Comment:

--

BluePrint/Messaging/Outbound

@@ -19 +19 @@
 (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.)
 
+Other issues we want to deal with:
+* Make sure queue runs do not overlap.
+* Must make sure that inserts while the queue is being processed are (thread) safe.
+
 === Options ===
-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:
-* 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:
+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:
+* 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:
   * Launch the new message queue asynchronously when each new message is posted. Here, there would be a periodic task just for the retry queue.
   * 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.
 * 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.
 
-Make sure queue runs do not overlap.
-Must make sure that inserts while the queue is being processed are (thread) safe.
+
 
 == Email Error Handling ==