Great! We'll talk more when I start using it shortly.
On Dec 2, 8:25 am, Vince Bonfanti wrote:
> Yes, I received your patch and it's on my TODO list to review it and add it
> to the code. Unfortunately, I've been a bit backed up with other projects.
> I'm trying to get a new version of GaeVFS re
Yes, I received your patch and it's on my TODO list to review it and add it
to the code. Unfortunately, I've been a bit backed up with other projects.
I'm trying to get a new version of GaeVFS ready for release in the next few
weeks and will try to include your patch.
Vince
On Wed, Dec 2, 2009 at
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
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
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
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 wrote:
> Vince, shouldn't you use an un-named Task qu
I'm not sure I follow the first part of your response--are you mixing up
"queue names" and "task names"?
But, yes, implementing a mutex via memcache works (I've already tested it),
but there are two things I don't like about this approach:
1) There's additional overhead of using memcache (about
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
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
