This repository is private.
All pages are served over SSL and all pushing and pulling is done over SSH.
No one may fork, clone, or view it unless they are added as a member.
Every repository with this icon (
) is private.
Every repository with this icon (
This repository is public.
Anyone may fork, clone, or view it.
Every repository with this icon (
) is public.
Every repository with this icon (
Loading…
Labels












Better still, is to use another backend, I think! The database backend is not very good for this kind of work. The most elegant and effective solution is the amqp backend. The amqp backend does not allow you to retrieve a result twice, but you could wrap it so it saves the result to the database the first time it's retrieved. The result would be very fast and with no polling.
What memory leak is this btw, are you talking about when settings.DEBUG is on?
This is related to how python memory managment interacts with django. When python allocates large amount of memory for django based models, even after all references to those objects are removed, memory won't get released. Have little time to investigate, but this may be problem related to the AppCache facility.
oh. then that's something that ought to be a problem elsewhere as well. One of our tasks using django models is leaking some, very little though, it can take months to go out of memory. Haven't tracked it down yet, but it may be related.
That's usually the problem whe you iterate over large datasets and would like to process django model instances with finite amount of memory. For example when parsing data to xml for some external service.