Seems like you can just setup a re-entrant task where when it gets close to 30 seconds (or a good place to pause) it calls out to another app (by url) that immediately calls back (to a place you can even specify on the request) with all the info needed to start back up and continue processing. Then you just have your task ping this restart/ resume service, and magically you get a request with where to start back up. Keep doing this as long as you need to do work.
Using cron to start these processes seems straight forward enough, and they can go one as long as you want by simpling ping'n yourself (essentially) continously. On Apr 9, 11:09 am, Stuart McCulloch <[email protected]> wrote: > 2009/4/10 Eduardo Nunes <[email protected]> > > > > > yes, but the main problem about the cron, is that it executes a URL, > > so you have only 30 seconds to do something, at least if they > > implemented the same restriction to "cron requests". Does anyone know > > something about it? > > yes the same 30s timeout is applied to cron jobs, and you can have a maximum > of 20 jobs > > On Thu, Apr 9, 2009 at 1:41 PM, Brian Pontarelli <[email protected]> > > > > > wrote: > > > > On Apr 9, 2009, at 10:21 AM, Stuart McCulloch wrote: > > > > 2009/4/10 Brian Pontarelli <[email protected]> > > > >> > yes the Google App Engine has a strict security manager - it also > > >> > doesn't allow you to create threads > > > >> Ouch. Sorta hinders applications that burst/multiplex backend services > > >> or that use schedulers. Wonder if they'll provide a thread pool at > > >> some point. > > > > yep - though there is a basic "cron" scheduler service: > > > > http://code.google.com/appengine/docs/java/config/cron.html > > > > Nice. > > > > also, requests have a time limit of 30s - after that they get zapped > > > > http://code.google.com/appengine/docs/java/runtime.html > > > > Even more reason to burst requests to backend service and do > > > things asynchronously inside the application rather than letting the GAE > > > truncate the connection. Adding a task execution service would solve it. > > You > > > could pin the task to the server that is handling the request or span it, > > > depending on how the tasks are implemented and if they can be > > distributed. > > > You could also define well known tasks in the appengine XML file and this > > > would allow distribution: > > > <task> > > > <class>com.example.BurstSomeBackendTask</class> > > > <!-- Additional task info --> > > > </task> > > > public class BurstSomeBackendTask implements Task { > > > public void execute(TaskRequest request, TaskResponse response) { > > > // do the task here > > > } > > > } > > > // Client > > > Map<String, String> data = ...; > > > TaskService ts = TaskServiceFactory.createTaskService(); > > > TaskResponse response = > > > ts.executeAndWait("com.example.BurstSomeBackendTask", data, 10); > > > TaskFuture tf = ts.execute("com.example.BurstSomeBackendTask", data); > > > > The data could also be a protobuffer or some other type of transport. > > > Plus, if anything wants to do NIO work, it will need to have selector > > > thread(s). > > > There are many reasons to use threads, so it seems that locking them down > > > would dictate that the GAE would need to provide alternative solutions. > > > -bp > > -- > Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" 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-guice?hl=en -~----------~----~----~----~------~----~------~--~---
