Changes between Version 14 and Version 15 of BluePrint/Messaging/Outbound
- Timestamp:
- 09/21/12 13:41:03 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrint/Messaging/Outbound
v14 v15 10 10 Right 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. 11 11 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.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 -- 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. 13 13 14 14 Consider these cases: … … 24 24 * Make sure queue runs do not overlap. 25 25 * 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.) 26 27 27 28 === Options === 28 29 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:30 Given 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: 30 31 * 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: 31 32 * Launch the new message queue asynchronously when each new message is posted. Here, there would be a periodic task just for the retry queue. … … 40 41 41 42 Initial part: 43 44 * If msg is enabled, queue up new messages rather than sending them directly. 42 45 43 46 * Split outbound processing into three queues: … … 63 66 64 67 * 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? 65 70 66 71 == Email Error Handling ==
