From 184545b33173195c5959cad489b5cc0d358a0481 Mon Sep 17 00:00:00 2001 From: webchick Date: Mon, 30 Jan 2012 23:49:11 -0800 Subject: Issue #1405260 by skottler: Clarify the language around non-reliable queue examples. --- modules/system/system.queue.inc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'modules') diff --git a/modules/system/system.queue.inc b/modules/system/system.queue.inc index 806015c24..47d8e7cc3 100644 --- a/modules/system/system.queue.inc +++ b/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). */ /** -- cgit v1.2.3