Thank you. That is my approach now, as well; however, I hoped to learn a better, more reliable solution.
On 8 Feb., 19:42, John Patterson <[email protected]> wrote: > HDEEs can be thrown without a DEE if it happens in your own code. > Usually the most time consuming thing is waiting for API calls to > return so a timeout here will result in the API call stopping with a > DEE. So if you do not call the API often you can hit HDEE directly. > > I also have long running tasks that iterate through data processing > and storing results. I use an Iterator that stops returning results > after 20 seconds and saves the last object processed and then kicks > off a new task to continue processing. > > My original solution caught the DEE and then cleaned up but this > stopped working reliably. > > On 9 Feb 2010, at 01:22, Moritz wrote: > > > > > Hello everyone, > > > in my application I have a scheduled task that runs every 5 minutes to > > update the cache. Currently it is a "brute force" implementation, that > > runs through all entities and computes all permutations required. > > > This task usually takes longer than 30 seconds - and fails almost > > every time with a HardDeadlineExceededError. > > > My problem is, that all available information currently is not clear > > about how to handle these errors. Maybe I missed it, but: > > > - The documentation is only about bandwidth, number of requests, API > > calls etc. > > - The API provides methods to measure number of CPU cycles > > (getCpuTimeInMegaCycles()), but doesn't warn about reaching the limit > > - In the discussion group I find some information such as "maximum > > duration of 30 seconds for each request", but that is actually quite > > unspecific. > > - HardDeadlineExceededError is not documented in the API docs. > > Somewhere I read that a DeadlineExceededException should be thrown > > before - but I catch any "Exception" and still produce a > > HardDeadlineExceededError > > > Of course, I could now just use a timer to run my job and terminate it > > gracefully shortly before 30 seconds are reached. But I'd prefer a > > better, more predictable and reliable option. Any suggestions? > > > Thanx, > > Moritz > > > -- > > You received this message because you are subscribed to the Google > > Groups "Google App Engine for Java" 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-java?hl=en > > . -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
