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.

Reply via email to