Changes between Version 9 and Version 10 of BluePrint/Messaging/Outbound
- Timestamp:
- 09/21/12 12:43:25 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrint/Messaging/Outbound
v9 v10 3 3 4 4 == Outbound Queue Performance == 5 5 6 === Issues === 7 6 8 We 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. 7 9 … … 24 26 25 27 === Options === 28 26 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: 27 30 * 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: … … 43 46 * Failures (immediately permanent fails and max retries exceeded) 44 47 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. 46 49 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 messagebehavior.50 * Include advice in the user guidelines for the above choices, based on the site's messaging behavior. 48 51 49 52 * Add logging of errors. Detect obvious misconfiguration and object strenuously. … … 56 59 57 60 == Email Error Handling == 61 58 62 Web2py'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.) 59 63
