Ah, short execution time and bullet-proof re-runs...I see how memcache would work in this case. On another topic, I recall you wrote GaeVFS...I recently added a comment related to a patch for checking file timestamp to avoid redundant downloads. On the surface it appears straight forward...if the http header was supplied then just compare with the Entity's timestamp and you're done. Is it really that simple? Are you or someone else familiar with the code considering adding this check?
On Dec 1, 4:34 pm, Vince Bonfanti <[email protected]> wrote: > Yes, obviously I can't use task names because of the 7-day expiration; I > just happened to be testing something else on the dev server when I noticed > that it behaved the way I wanted. > > In my case the unreliability of memcache isn't too much of a concern for two > reasons. First, I expect the tasks be executed relatively quickly--within a > few hundred milliseconds--and hopefully memcache can be relied upon for at > least that long. Second, there's no real harm if my tasks get executed more > than once. > > I just opened a new issue on this, if you want to go star it: > > http://code.google.com/p/googleappengine/issues/detail?id=2459 > > Vince > > > > On Tue, Dec 1, 2009 at 5:24 PM, James H <[email protected]> wrote: > > Sorry, I was writing my 2nd reply prior to seeing yours...but I mean't > > don't specify a Task Name in order to free yourself from the > > rediculous 7-day rule (what good is that?). So really since memcache > > is not a good choice for sensitive mutable data such as a mutex, you'd > > have to implement your own as I suggested. I'll be curious to hear > > other alternatives since this would be a common requirement in apps! > > > On Dec 1, 4:17 pm, James H <[email protected]> wrote: > > > Also, the nature of memcache is such that it would not be reliable for > > > a mutex (since objects can be removed by the system at any time > > > regardless if Task N is running), hence the potential for duplicate > > > task entries. > > > > On Dec 1, 4:08 pm, James H <[email protected]> wrote: > > > > > Vince, shouldn't you use an un-named Task queue (to avoid Naming rules > > > > mentioned) but query your own datastore semaphore prior to adding to > > > > the queue. This way when task N runs it manages the semaphore (a > > > > Entity) to implement a mutex begin/end sequence. I believe this > > > > implies that task N will in fact run 3 transactions: #1 - mutex begin > > > > (create Entity), #2 - work for N, and #3 - mutex end (remove Entity). > > > > > Anyhow assuming your logic to trigger a new Task N can incorporate the > > > > criteria for mutex exists, then what would keep this from working? > > > > > On Dec 1, 2:37 pm, Vince Bonfanti <[email protected]> wrote: > > > > > > BTW, I've noticed that the dev server actually behaves the way I > > would like > > > > > it to. It only throws a "Task name already exists" exception while > > the task > > > > > is queued; as soon as the task runs it allows you to queue up another > > task > > > > > with the same name. > > > > > > I guess I'll just open a feature request on this in the issue > > tracker. > > > > > > Vince > > > > > > On Tue, Dec 1, 2009 at 11:39 AM, Vince Bonfanti <[email protected]> > > wrote: > > > > > > I'm trying to solve the following problem using task queues: > > > > > > > 1. Queue a task to perform some action "N". > > > > > > 2. Until action N has been performed, don't allow any other tasks > > to be > > > > > > queued that also perform action N. > > > > > > 3. As soon as action N has been performed, immediately allow > > other tasks > > > > > > to be queued to perform action N (repeat from step 1). > > > > > > > Using task names almost accomplishes what I need, except that at > > step 3 it > > > > > > will be at least seven days before another task can be queued to > > perform > > > > > > action N, when I need it to be allowed immediately: > > > > > > > "This (task names) provides a lightweight mechanism for ensuring > > > > > > once-only semantics. Once a Task with name N is written, any > > subsequent > > > > > > attempts to insert a Task named N will fail. Eventually (at least > > seven days > > > > > > after the task successfully executes), the task will be deleted and > > the name > > > > > > N can be reused." > > > > > > > I've thought of different ways to solve this, most likely by using > > a > > > > > > memcache flag as a semaphore. But, it would be nice if the task > > queue API > > > > > > could support this natively, maybe by adding a "reuse time" or > > "exclusion > > > > > > time" parameter when setting the TaskOptions name parameter. > > > > > > > Any thoughts on this? > > > > > > > Vince- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > -- > > > 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]<google-appengine-java%2b[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en.- Hide quoted > >text - > > - Show quoted text - -- 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.
