Thanks everyone, I'd like to say that I ended up using django-celery + RabbitMQ server. But had some problems trying to make celery run as daemon. After sometime I discovered what need to be done(didn't like the docs in this part... found them misleading), everything is working great.
Even made a post about this: http://www.arruda.blog.br/programacao/django-celery-in-daemon/ Thanks Em terça-feira, 20 de março de 2012 12h11min11s UTC-3, Jani Tiainen escreveu: > > Hi, > > Your solution will work perfectly in single process environment (For > example with manage.py runserver ) > > But when you put your app behind webserver you usually invoke several > processes. For example if you're using single round-robin loadbalancing > over 5 different Django instances. > > What would happen if Django instances are restarted after n cycles (like > our wsgi django instances are restarted after 1000 requests). Can you > guarantee that your thread survives? > > If you do "massive" scaling: what happens if you have multiple servers, > how can you guarantee that consecutive requests from single user goes to > same server and same process? > > That is why there exists things like django-celery and rabbitmq (message > broker). How they work is already explained to you. > > 20.3.2012 16:52, Arruda kirjoitti: > > Thanks every one, I've manage to work this around. > > The solution might not be the best, but it's working: > > In the view I call the *do_something_slow()* in a new thread, and in the > > end of it(after the role process is done) it change the model of a class > > to add the feedback. > > While the thread is running it renders the template to the user(with a > > *"Loading..."* message). > > Then I've made a *ajax_get_feed_back() *view to get this feedback. > > > > In the template, I made a simple JS that every second tries to get the > > feedback via ajax. > > And if it gets the feedback it stops requesting it. > > =) > > > > But I still wanted to know how to use the celery in this case =/ > > But got very lost in that, does any one have a example(code) of > > something similar to do with it? > > In the docs I only found examples of process that are kind of tasks... > > to run every hour, or things like that. > > > > Em segunda-feira, 19 de mar�o de 2012 15h18min09s UTC-3, Arruda > escreveu: > > > > *(I've created a topic like this a few minutes ago, but was using > > the old google groups, and now it's broken. So I created a new one > > using the new google groups).* > > Hi, I'll try to explain the best I can my problem, and I don't know > if > > what I'm trying to archive is the best way to get where I want, but > > here is it: > > I want that a specific view to run in a new thread, ex: > > *def foo(request): > > do_something_slow() > > return httpResponse* > > > > But I DON'T want that a new thread is run inside the view, the view > it > > self should be runned in another thread, ex: > > * > > def foo(request): > > t = thread(target=do_something_slow()....) > > t.daemon = True > > t.start() > > > > return httpResponse > > * > > This way when a user A access any page the site will load, even if a > > user B is accessing the 'foo' view. > > But the B user when access the view 'foo' will load it just a if if > > was a normal view( will be slow and will render the response just > > after do_something_slow() finished running). > > > > I don't know if this is what I want, but I believe that there is > > another way around: > > when user B calls foo view, it will render to him a page with a JS(I > > don't know JS either, so correct me if I'm talking nonsense) that say > > its "Loading..." > > And after the do_someting_slow() finished running if will change the > > content of the page to whatever the result of "do_something_slow" > was. > > > > Thanks for the attention. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Django users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-users/-/ST6KqE0uPqsJ. > > 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. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/__-Eyqv2_4cJ. 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.