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?
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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
