convore.json/groups/django-community/idempotent-task-queueing/messages.json

[{"user_id": 115, "stars": [], "topic_id": 21551, "date_created": 1303871988.253819, "message": "ow can I make celery ignore duplicate tasks with the same task_id? Or achieve a similar effect. I though it did this by default, but apparently not.", "group_id": 81, "id": 820980}, {"user_id": 115, "stars": [], "topic_id": 21551, "date_created": 1303872050.308902, "message": "er, \"How\"", "group_id": 81, "id": 820988}, {"user_id": 115, "stars": [], "topic_id": 21551, "date_created": 1303874961.023344, "message": "fwiw, ended up making a wrapper that writes to a db row", "group_id": 81, "id": 821575}, {"user_id": 141, "stars": [], "topic_id": 21551, "date_created": 1303879194.7996981, "message": "they suggest using the cache as a makeshift lock http://celeryq.org/docs/cookbook/tasks.html#ensuring-a-task-is-only-executed-one-at-a-time", "group_id": 81, "id": 822087}, {"user_id": 257, "stars": [], "topic_id": 21551, "date_created": 1303896825.168, "message": "and is not supported by celery, because it requires a database/service to keep track of the seen task ids", "group_id": 81, "id": 823861}, {"user_id": 115, "stars": [], "topic_id": 21551, "date_created": 1303897317.2455959, "message": "@asksol Yes, that makes sense. Thank you for the explanation. I'm using a simple SQL table, since I'm not already using Redis for this project.", "group_id": 81, "id": 823913}, {"user_id": 257, "stars": [], "topic_id": 21551, "date_created": 1303896785.3315139, "message": "what you talk about is called deduplication", "group_id": 81, "id": 823857}, {"user_id": 257, "stars": [], "topic_id": 21551, "date_created": 1303896774.826637, "message": "cache or redis", "group_id": 81, "id": 823856}, {"user_id": 115, "stars": [], "topic_id": 21551, "date_created": 1303897175.945365, "message": "@markpasc that's not quite the same thing", "group_id": 81, "id": 823897}, {"user_id": 11, "stars": [{"date_created": 1304450113.2643509, "user_id": 141}], "topic_id": 21551, "date_created": 1304444306.4554491, "message": "FWIW, this is not really as simple as it sounds... in the world of queueing you really have to accept the possibility of either duped messages or dropped messages. It's sort of the CAP theorem equivalent for queueing. A common tradeoff is a time-threshold during which messages can be de-duped (TCP does this) - so you'd keep track of message IDs (or hashes, or the whole message) for some period of time so you can de-dupe if you receive a dupe within, say, 15 minutes.", "group_id": 81, "id": 900694}]