On Tue, Apr 3, 2012 at 11:25 PM, Andre Terra <andrete...@gmail.com> wrote: > Hey Javier, > > Thanks for the reply. My problem with the logs in the past was that they > tended to make the task even slower (due to recursion) but I guess that's > probably because I didn't call the logging from the appropriate places in > the code. > > To make things a little more complicated, the task involves writing a large > amount of data to a temp database, handling it and then saving some > resulting queries to the permanent DB. This makes it a tad harder to analyze > what goes on in the first part of the code. > > I'll try logging again over the weekend and see how that works.. I just wish > there were third party apps and tools for debugging this sort of problem. > > Thanks again for your input. > > Cheers, > AT
Hi Andre One pretty cool method I've used for live debugging in the past is to 'log' to rabbitmq (Note - not celery - raw amqp), and send messages to a logging exchange. You can use a topic key so that different processes can be distinguished. Then, if you want to see the running logs of what is happening, you simply attach a dumb listener that binds a queue to that exchange, receives the message and prints it out. If you're no longer interested, detach the listener, and rabbitmq will just discard the messages with little overhead. If you want to do stuff with AMQP, I'd recommend pika [1], which is just brilliant and easy to understand (other amqp libraries, less so!). Cheers Tom [1] http://pika.github.com/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
