On Mon, Feb 1, 2016 at 10:49 PM, Mario R. Osorio
wrote:
> y So this is effectively a feed aggregation engine. I would recommend
>> having a separate daemon running per media source, so that issues with one
>> media source do not affect the operations of another.
>>
>
> I
>
> y So this is effectively a feed aggregation engine. I would recommend
> having a separate daemon running per media source, so that issues with one
> media source do not affect the operations of another.
>
I never would have thought of this application as a feed aggregation
engine, but
>
> I suggest that you use Celery.
>
A very useful tip!
>
> If people are making HTTP requests of you, that is reason enough to choose
> Django.
>
Well, let me put it this way; I felt in love with Python almost 7 years
ago, but when I met Django, this love turned into an obsession you see;
I understand HTTP requests are short lived, I just could not figure out how
to handle the possible long responses, I' m rather new to python AND to web
programming and when I start mixing things like WSGI my brain just burst. I
know about celery, just never thought it would be my allied in this
Thanks to each and every one of you for the VERY HELPFUL recommendations
you have given me (Avraham Serour, ke1g & James Schneider so far) I really
got back more than I expected, but as I told a friend of mine; it was worth
every minute of the almost 4 hours it took me to redact this question,
On Sun, Jan 31, 2016 at 8:51 PM, Mario R. Osorio
wrote:
> I need comments on an application I have been recently proposed. The way
> it is being envisioned at this moment is this:
>
>
> One python daemon will be listening for different communications media
> such as email,
I suggest that you use Celery.
If people are making HTTP requests of you, that is reason enough to choose
Django.
But do not wait for long calculations to complete before returning an HTTP
result. Instead redirect to a page containing simple JavaScript that will
poll for a result.
PostgreSQL
if a process takes too long to complete it won't be able to process new
requests, so you will be limited to the number of workers you told uwsgi to
use.
http requests should be short lived, if you have some heavy processing to
do the http request should return with something like 'accepted' and
I need comments on an application I have been recently proposed. The way it
is being envisioned at this moment is this:
One python daemon will be listening for different communications media such
as email, web and SMS (web also). IMHO, it is necessary to have a daemon
per each media. This
9 matches
Mail list logo