The decision to rerun a task is done based on the HTTP response code. There is always a response code, even when the connection is lost.
When the code is 200 the task is considered complete and will not be rerun. Any other code means the task needs a rerun. The time between the reruns is increased with each retry. This means a certain task is never retried in parallel. But it could be that a task created later will finish first because it did not need to retry. 2010/4/25 hawkett <[email protected]>: > Wondering if I haven't asked the question clearly enough. Regarding > the statement that we need to assume tasks may be executed multiple > times (i.e. ensure idempotence): is that multiple times serially, or > possibly multiple times concurrently? > > I've gone ahead and coded my idempotence solution to assume that they > cannot be running concurrently, just because its a bit easier, and a > bit less work inside a transaction. I'm guessing that the reason they > may be run multiple times is that GAE won't know what to do if it > doesn't get a response from a task it executes - it can't be sure that > the task was received by the application, or that the application was > given the opportunity to correctly react the task - in fact it has to > assume that it didn't, and therefore runs it again to be sure. I'm > assuming that GAE always knows for certain that a task has been fired, > just not whether it was fired successfully - and it will only fire > again if it hasn't correctly processed a response from the previous > execution. If this were true, then it seems as long as GAE guarantees > that it waits > 30s before firing the task a second time (rather than > just reacting to the loss of the http connection for example), then we > can know it is not executing in parallel, because the first execution > cannot be still running due to the request limit. > > Am I looking at this correctly? Is it fair to assume that the same > task cannot be running in parallel? Cheers, > > Colin > > > > On Apr 23, 3:14 pm, hawkett <[email protected]> wrote: >> Hi Tim - there's a couple of reasons why this won't work - firstly, it >> is my understanding that named tasks are also subject to the >> possibility of being executed twice (the name only prevents the same >> name being added to the queue twice), and secondly tasks raised >> transactionally cannot have a task name. >> >> On Apr 23, 11:45 am, Tim Hoffman <[email protected]> wrote: >> >> >> >> >> >> > Probably the best way to guard would be have the task name specific to >> > the operation. >> > You cant have another task with the same name for about a week, >> >> > T >> >> > On Apr 23, 3:51 pm, hawkett <[email protected]> wrote: >> >> > > HI, >> >> > > I understand that it is possible for a single task to be executed more >> > > than once, but is it safe to assume that only one instance of a >> > > specific task will be executing at the one time? It makes it much more >> > > difficult (time consuming) to implement idempotent behaviour if it is >> > > possible for the subsequent executions of a task to begin before the >> > > first has completed - i.e. for the same task to be executing >> > > concurrently. I can think of ways of using db locking (memcache is not >> > > reliable - especially when this scenario is most likely to occur >> > > during system failures) to recognise the multiple concurrent >> > > executions, but it would be great to know that this scenario cannot >> > > occur. Thanks, >> >> > > Colin >> >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "Google App Engine" group. >> > > To post to this group, send email to [email protected]. >> > > To unsubscribe from this group, send email to >> > > [email protected]. >> > > For more options, visit this group >> > > athttp://groups.google.com/group/google-appengine?hl=en. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Google App Engine" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/google-appengine?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group >> athttp://groups.google.com/group/google-appengine?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
