mirror of
https://github.com/not-kennethreitz/convore.json.git
synced 2026-06-20 15:10:58 +00:00
1 line
5.4 KiB
JSON
1 line
5.4 KiB
JSON
[{"user_id": 2588, "stars": [{"date_created": 1303561448.525913, "user_id": 20170}], "topic_id": 20839, "date_created": 1303482157.909277, "message": "Pros I see are increased visibility (declared in settings rather than a cron template in our deploy dir that nobody ever looks at), and an easier path for local development since we already use celery for some async processing (no extra steps installing crontab)", "group_id": 81, "id": 781730}, {"user_id": 2588, "stars": [], "topic_id": 20839, "date_created": 1303481928.2164099, "message": "I have a project with a mix of cron jobs and a few things that were implemented as celery tasks and added to celerybeat schedule. I'm thinking of moving everything to periodic celery tasks. Anyone hit any snags going this route?", "group_id": 81, "id": 781718}, {"user_id": 2588, "stars": [], "topic_id": 20839, "date_created": 1303482186.7399919, "message": "Of course, you know what you're getting with cron and I don't have experience using celery in a production environment.", "group_id": 81, "id": 781735}, {"user_id": 1127, "stars": [], "topic_id": 20839, "date_created": 1303488745.840502, "message": "There also may be something that already implements my suggested cron.py as well (for some reason I feel like a django-cron has to exist)", "group_id": 81, "id": 782460}, {"user_id": 1127, "stars": [{"date_created": 1303512171.2433431, "user_id": 13912}], "topic_id": 20839, "date_created": 1303488724.406445, "message": "I would choose Celery under the assumption that you will use it for more than just periodic tasks. If not, write a simple cron.py that executes every minute and register things against it.", "group_id": 81, "id": 782458}, {"user_id": 2588, "stars": [], "topic_id": 20839, "date_created": 1303490697.771163, "message": "We're already using Celery for some async processing so it's a natural step to go in that direction. I'm just not as aware of the track record of stability for the beat aspect of celery.", "group_id": 81, "id": 782876}, {"user_id": 1127, "stars": [], "topic_id": 20839, "date_created": 1303492691.8450501, "message": "I don't think we're using it currently, but I've used it in other projects and don't remember ever seeing any issues", "group_id": 81, "id": 783189}, {"user_id": 213, "stars": [], "topic_id": 20839, "date_created": 1303496622.2967861, "message": "@unbracketed: I've been meaning to look at https://github.com/dmgctrl/django-ztask which seems like a neat idea, having a small footprint et al. Haven't tried it yet though.", "group_id": 81, "id": 783717}, {"user_id": 213, "stars": [], "topic_id": 20839, "date_created": 1303496631.059196, "message": "and yeah, I think this was OT :D", "group_id": 81, "id": 783720}, {"user_id": 2588, "stars": [], "topic_id": 20839, "date_created": 1303498423.1614461, "message": "@jezdez I just stumbled across that myself. Looks interesting!", "group_id": 81, "id": 783982}, {"user_id": 1127, "stars": [], "topic_id": 20839, "date_created": 1303510115.110482, "message": "@jezdez ztask seems too trendy -- not really a fan of them reinventing Celery with less features (and requiring ZeroMQ)", "group_id": 81, "id": 785597}, {"user_id": 213, "stars": [], "topic_id": 20839, "date_created": 1303514195.9683609, "message": "@zeeg uh not sure what you mean with \"too trendy\" to be honest, but whatever, I'll shut up till I've tried it actually :)", "group_id": 81, "id": 786042}, {"user_id": 2362, "stars": [], "topic_id": 20839, "date_created": 1303536919.9123859, "message": "We use celery for scheduled tasks with great results. I can't recommend it enough.", "group_id": 81, "id": 787558}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303556882.033556, "message": "jezdez: did you read the ztask code? :)", "group_id": 81, "id": 788431}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303557154.4338169, "message": "but it's obvious they have no intention of supporting multiple workers", "group_id": 81, "id": 788446}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303557077.7172871, "message": "I'd say that would require a lot of work before it's a good solution", "group_id": 81, "id": 788439}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303558343.364156, "message": "e.g. with the above persistency model, what do you do if the worker is offline? the tasks will be lost", "group_id": 81, "id": 788515}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303557707.7997661, "message": "I kind of like the idea of using zeromq to avoid unecessary polling of the db though, but it should be the other way around. In ztask the clients sends the message through the zeromq socket (directly to the worker), and THEN the worker writes the task to the db if the task fails (what they call persistence)", "group_id": 81, "id": 788492}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303557786.831111, "message": "The clients should write the task to the database, thus making sure the data is written (depending guarantees from the database of course), then simply signal the workers to say there is a new task available", "group_id": 81, "id": 788495}, {"user_id": 257, "stars": [], "topic_id": 20839, "date_created": 1303558140.267112, "message": "think I may play with this, but as 0mq is brokerless it's harder if you want multiple workers. Either every client needs to know what workers are available by config, or you need a separate name service", "group_id": 81, "id": 788506}] |