summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwebchick2012-01-31 07:48:51 (GMT)
committer webchick2012-01-31 07:48:51 (GMT)
commit853ae41231d3b15b3bf1b174224c117b955a9a74 (patch)
tree759b1cb85de5dbaa10a13e4b0a0da3b1fcc6b73a
parent148f5b6f28b1257a7bedc1b2ce6a897d27dc7794 (diff)
Issue #1405260 by skottler: Clarify the language around non-reliable queue examples.
-rw-r--r--core/modules/system/system.queue.inc14
1 files changed, 7 insertions, 7 deletions
diff --git a/core/modules/system/system.queue.inc b/core/modules/system/system.queue.inc
index 00d3940..c2a6b13 100644
--- a/core/modules/system/system.queue.inc
+++ b/core/modules/system/system.queue.inc
@@ -45,13 +45,13 @@
* would be an in-memory queue backend which might lose items if it crashes.
* However, such a backend would be able to deal with significantly more writes
* than a reliable queue and for many tasks this is more important. See
- * aggregator_cron() for an example of how can this not be a problem. Another
- * example is doing Twitter statistics -- the small possibility of losing a few
- * items is insignificant next to power of the queue being able to keep up with
- * writes. As described in the processing section, regardless of the queue
- * being reliable or not, the processing code should be aware that an item
- * might be handed over for processing more than once (because the processing
- * code might time out before it finishes).
+ * aggregator_cron() for an example of how to effectively utilize a
+ * non-reliable queue. Another example is doing Twitter statistics -- the small
+ * possibility of losing a few items is insignificant next to power of the
+ * queue being able to keep up with writes. As described in the processing
+ * section, regardless of the queue being reliable or not, the processing code
+ * should be aware that an item might be handed over for processing more than
+ * once (because the processing code might time out before it finishes).
*/
/**