On Sunday, November 30, 2014 1:51:37 PM UTC+1, nick name wrote:
>
> Is that true even with immediate=True? If so, what is the recommended way
> to reduce this to 0.5 seconds or so? I have an app in which a user requests
> somethng; that request launches 1-10 other web requests, and the user kee
Is that true even with immediate=True? If so, what is the recommended way
to reduce this to 0.5 seconds or so? I have an app in which a user requests
somethng; that request launches 1-10 other web requests, and the user keeps
refreshing until they all complete for the summarized result. (I will
when nothing is going wrong, and with default values, you can expect to
queue a task and have it assigned in 15 seconds. if that's not the case,
something is going "wrong" (other tasks are being processed, workers not
ready, db contention, etc etc etc)
On Friday, November 28, 2014 8:02:15 PM UT
Il 28/11/14 18:30, Niphlod ha scritto:
> |
> deftest():
> newid =sched.queue_task(,immediate=True)
> db.commit()#the db instance where the scheduler is
> whileTrue:
> rtn =sched.task_status(newid)
> ifrtn.status =='COMPLETED':
>...blablabla
>
Related, but not exactly the same question:
I'm submitting an immediate task in a regular (no sleep or anything --
though no special commit either); I can see it's queued for seconds and
sometimes minutes before getting assigned and running.
There are no other tasks waiting or running, there ar
def test():
newid = sched.queue_task(, immediate=True)
db.commit() #the db instance where the scheduler is
while True:
rtn = sched.task_status(newid)
if rtn.status == 'COMPLETED':
...blablabla
break
time.sleep(3)
not test
6 matches
Mail list logo
