Re: [google-appengine] Re: Design Question - How to simulate efficient joins

[Jeff Schnitzer]

On Thu, Oct 27, 2011 at 2:16 PM, Jose Montes de Oca <
jfmontesde...@google.com> wrote:

>
> On Thursday, October 27, 2011 1:06:16 PM UTC-7, Jeff Schnitzer wrote:
>>
>> I'm going to be the dissenting here.  You should consider #1 if you know
>> that you're always going to have on the order of 100 items.  You can easily
>> cache this value in memcache.
>
>
> IMO this would depend on the size of the items, fetching 100 items and
> then traversing then to do a simple sum could be a great overhead on read
> time that could be avoid by doing this on write time. (This is App Engine
> strategy for queries)
>

Sure, it depends on entity size... but the "typical" entity not so large
that this is an issue, and the OP's Score entity sounds tiny.  If he can
cache for any length of time, computation is a non-issue.

It also depends on change rate.  If the data changes frequently, it will
likely be significantly cheaper and easier to calculate it ad-hoc rather
than pre-calculating.  Especially if he doesn't need instantaneously
accurate results.


> If you do an ancestor query you will get consistent data.
>

...but only if you have everything in one entity group.  Everything is a
tradeoff.

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Deploy drops data

[Simon Knott]

Hi,

Are you talking about deploying into Production GAE, or into the 
development server?  Deploying into Production GAE will never clear down 
any data, as far as I'm aware.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/yLtMreDLaHUJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: URGENT: memcache errors out on write, the entire site is down

[Johan Euphrosine]

Could you open a bug on the public issue tracker ?
http://code.google.com/p/googleappengine/issues/entry?template=Java%20defect

If you can please attach an unittest that exhibit the bad behaviour.

Thanks in advance.

On Fri, Oct 28, 2011 at 12:07 AM, Simon Knott  wrote:
> Now that I've got some caffeine in my system, I'll correct myself - it looks
> like the error handler isn't used for "put" operations at all and it's
> possible that individual increment calls with fail non-silently as well.
> The rest of the calls either use the error handler correctly, or just fail
> silently anyway.
>
> Cheers,
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/wqNb9L1OX4cJ.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>



-- 
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Emails sent from GAE apps to yahoo or hotmail addresses get tagged as spam

[Rishi Arora]

I like the SMS validation idea.  Although I imagine that many users may not
be willing to divulge their phone numbers.  What worked for me was to not
have a reply_to field, and have the sender be "
no-re...@app-id.appspotmail.com".

On Thu, Oct 27, 2011 at 8:49 AM, Barry Hunter wrote:

> On Thu, Oct 27, 2011 at 2:07 AM, Greg  wrote:
> > On Oct 27, 12:45 am, Joshua Smith  wrote:
>
> >
> > I'm about to move to SMS verification because if Google does it, it's
> > likely the best solution.
>
> I think the reason google do it is to manage people signing up for
> multiple accounts (lots of incentive with the generous free quota) -
> its a lot harder to get lots of disposable mobile numbers, than it is
> to get another email address.
>
> It doesnt  'verify' the email as such, so still subject to typos etc.
> It does however help with fighting spambots...
>
>
> (and search this group for links to the sms waitlist form. Lots of
> people obvisoully fail to pass sms validation)
>
>
>
>
>
> >
> > Cheers
> > Greg.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> > To post to this group, send email to google-appengine@googlegroups.com.
> > To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: The Dining Philosophers

[Emlyn]

On 28 October 2011 12:19, Brandon Wirtz  wrote:
> I would think that it would make more sense to store the last read Memcache
> state to instance memory (basically free), if Memcache is flushed detect and
> upload last state to memcache.

There's no way to guarantee it'd be there, is there? The task that
runs and find out that there's no memcache might be in an entirely new
instance.


> -Original Message-
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Emlyn
> Sent: Thursday, October 27, 2011 5:04 PM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Re: The Dining Philosophers
>
> Germ of an idea:
>
> Assume we can implement semaphore entirely in memcache, ignoring the fact
> that it can be flushed.
>
> Then, to cope with being flushed, we could have an idea of a Semaphore as
> being in one of three states; Ok, Gone and Restarting.
>
> Ok is just normal operation
> Gone is when you know it's been flushed
> You detect Gone by noticing the problem when you try to touch the Semaphore
> (in Wait() and Signal() calls). You restart the Semaphore.
> Restarting is a period where you are trying to get back to Ok state.
>
> Basically, the idea will be that if the Semaphore disappears, we go into a
> state (Restarting) where we are going to wait for a while until we can know
> that the semaphore should be unused, then reset it to it's initial state
> (ie: unused) and we're good to go again. The way we'll do this is to wait a
> bit for anyone who might be using the semaphore to finish, and then once
> we've waiting long enough, we just assume everyone is done and proceed. It's
> a timeout, and it means imposing a maximum time length on holding the
> Semaphore that callers need to obey.
>
> Semaphores have two bits of internal state which needs to be maintained:
> - Counter
> - Wait List
>
> The Wait list really needs to be in the datastore, because if it gets
> flushed there's just no way to reconstitute it, Waiters will be lost
> forever.
> But the counter has more promise.
>
> Try an algorithm like this:
>
> Semaphores only have two methods which need to accomodate these states:
> Wait()
>   Touch the semaphore. What state are we in?
>   OK: Proceed as normal (if the counter is above zero then decrement it and
> proceed, else suspend on the wait list)
>   GONE: Reconstruct the semaphore in Restarting state. Suspend on the wait
> list.
>   RESTARTING: Suspend on the wait list.
>
> Signal()
>   Touch the semaphore. What state are we in?
>   OK: Proceed as normal (if there is anyone on the wait list, awaken one.
> Otherwise, just increment the counter)
>   GONE: Reconstruct the semaphore in RESTARTING state. Increment the
> counter. If it's equal to TokenMax, then Start the semaphore.
>   RESTARTING: Increment the counter. If it's equal to TokenMax, then Start
> the semaphore.
>
> Semaphores are extended as follows:
>
> A reconstructed Semaphore in RESTARTING state is initialised with Counter =
> 0.
>
> We are going to restart the semaphore by
> - defining a maximum length of time that a Semaphore token can be held (if
> you're using Front End tasks, just set it longer than the maximum task
> length).
> - when we restart, we schedule a Start task for a time in the future equal
> to the maximum task length.
> - When the Start task runs, it checks the Semaphore. If it's still in
> RESTARTING state, it Starts the Semaphore.
> - There is an ABA problem here. A Start task is scheduled, the Semaphore
> restarts before the task runs, then goes back into GONE and RESTARTING again
> (and another Start task is kicked off), then the original Start task runs
> and prematurely wakes the Semaphore. Fix this by adding a StartTaskID (uuid)
> to the Semaphore, generate a new one each time the Start Task runs, and pass
> it to the Start Task. An old StartTask will have the wrong uuid and can
> terminate itself based on that.
>
> Start the Semaphore:
> Either in the Start Task, or as the result of a Signal, we've determined
> that it's ok to Start the semaphore. So set the Counter to MaxCounter and
> change the state to OK. If there is anyone on the Wait List, wake as many of
> them as the counter allows, decrementing the counter for each one.
>
> ===
>
> I think this approach can work, and the cool thing is that the counter and
> the state should be implementable in Memcache. If the resource you're using
> isn't normally under contention (very commonly this is true, contention is
> unusual), then your most common operations will be in Memcache and wont
> touch the datastore. This also assumes that cache flushing is uncommon (if
> it flushed often, then it should still be correct, but the performance will
> be poor, because the restarting process is pretty slow). If the cache
> flushes really, really often (sub second?) then you'll starve, but I don't
> think memcache does that!
>
> Any thoughts?
>
> On 27 October 2011 23:24, Emlyn  wrote:
>> Tha

RE: [google-appengine] Re: Error creating new GAE application. Now App-ID seems to be permanently inaccessible

[Brandon Wirtz]

Yep. So while you get a logical name now  some time in the future all your
names are likely to be interesting hashes… especially since many of the good
names were taken by domain squatters when GAE was a great way to get high
quality in links from static pages.

 

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Martin Rösch
Sent: Thursday, October 27, 2011 6:15 PM
To: google-appengine@googlegroups.com
Subject: [google-appengine] Re: Error creating new GAE application. Now
App-ID seems to be permanently inaccessible

 

If I understand the App Engine documentation right, there is no way to
re-use an application name. It seems to be burnt forever. 

-- 
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/jOykly0EWZoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: The Dining Philosophers

[Brandon Wirtz]

I would think that it would make more sense to store the last read Memcache
state to instance memory (basically free), if Memcache is flushed detect and
upload last state to memcache.


-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Emlyn
Sent: Thursday, October 27, 2011 5:04 PM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Re: The Dining Philosophers

Germ of an idea:

Assume we can implement semaphore entirely in memcache, ignoring the fact
that it can be flushed.

Then, to cope with being flushed, we could have an idea of a Semaphore as
being in one of three states; Ok, Gone and Restarting.

Ok is just normal operation
Gone is when you know it's been flushed
You detect Gone by noticing the problem when you try to touch the Semaphore
(in Wait() and Signal() calls). You restart the Semaphore.
Restarting is a period where you are trying to get back to Ok state.

Basically, the idea will be that if the Semaphore disappears, we go into a
state (Restarting) where we are going to wait for a while until we can know
that the semaphore should be unused, then reset it to it's initial state
(ie: unused) and we're good to go again. The way we'll do this is to wait a
bit for anyone who might be using the semaphore to finish, and then once
we've waiting long enough, we just assume everyone is done and proceed. It's
a timeout, and it means imposing a maximum time length on holding the
Semaphore that callers need to obey.

Semaphores have two bits of internal state which needs to be maintained:
- Counter
- Wait List

The Wait list really needs to be in the datastore, because if it gets
flushed there's just no way to reconstitute it, Waiters will be lost
forever.
But the counter has more promise.

Try an algorithm like this:

Semaphores only have two methods which need to accomodate these states:
Wait()
   Touch the semaphore. What state are we in?
   OK: Proceed as normal (if the counter is above zero then decrement it and
proceed, else suspend on the wait list)
   GONE: Reconstruct the semaphore in Restarting state. Suspend on the wait
list.
   RESTARTING: Suspend on the wait list.

Signal()
   Touch the semaphore. What state are we in?
   OK: Proceed as normal (if there is anyone on the wait list, awaken one.
Otherwise, just increment the counter)
   GONE: Reconstruct the semaphore in RESTARTING state. Increment the
counter. If it's equal to TokenMax, then Start the semaphore.
   RESTARTING: Increment the counter. If it's equal to TokenMax, then Start
the semaphore.

Semaphores are extended as follows:

A reconstructed Semaphore in RESTARTING state is initialised with Counter =
0.

We are going to restart the semaphore by
- defining a maximum length of time that a Semaphore token can be held (if
you're using Front End tasks, just set it longer than the maximum task
length).
- when we restart, we schedule a Start task for a time in the future equal
to the maximum task length.
- When the Start task runs, it checks the Semaphore. If it's still in
RESTARTING state, it Starts the Semaphore.
- There is an ABA problem here. A Start task is scheduled, the Semaphore
restarts before the task runs, then goes back into GONE and RESTARTING again
(and another Start task is kicked off), then the original Start task runs
and prematurely wakes the Semaphore. Fix this by adding a StartTaskID (uuid)
to the Semaphore, generate a new one each time the Start Task runs, and pass
it to the Start Task. An old StartTask will have the wrong uuid and can
terminate itself based on that.

Start the Semaphore:
Either in the Start Task, or as the result of a Signal, we've determined
that it's ok to Start the semaphore. So set the Counter to MaxCounter and
change the state to OK. If there is anyone on the Wait List, wake as many of
them as the counter allows, decrementing the counter for each one.

===

I think this approach can work, and the cool thing is that the counter and
the state should be implementable in Memcache. If the resource you're using
isn't normally under contention (very commonly this is true, contention is
unusual), then your most common operations will be in Memcache and wont
touch the datastore. This also assumes that cache flushing is uncommon (if
it flushed often, then it should still be correct, but the performance will
be poor, because the restarting process is pretty slow). If the cache
flushes really, really often (sub second?) then you'll starve, but I don't
think memcache does that!

Any thoughts?

On 27 October 2011 23:24, Emlyn  wrote:
> Thanks, I had no idea that Memcache was so capable (I haven't looked 
> closely enough recently). You could absolutely build a semaphore using 
> those methods (cas would do the job nicely). Except of course that it 
> could disappear at any moment. I can't help thinking that there must 
> be some way to cope with that, however. Worth a ponder!
>
> On 27 October 2011 18:53, Murph 

[google-appengine] Re: New Application ID

[Martin Rösch]

additional information: even though I created a new google account for me, 
App Engine found the old one. Maybe this is the source of confusion? 

So my account is considered to be new (hence the Verify page) but it is old 
because my SMS number has been used already.

Hope that helps.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/NLocsQCu_4YJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Error creating new GAE application. Now App-ID seems to be permanently inaccessible

[Martin Rösch]

If I understand the App Engine documentation right, there is no way to 
re-use an application name. It seems to be burnt forever.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/jOykly0EWZoJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] New Application ID

[Martin Rösch]

When I try to create a new application in "My Applications" by clicking the 
"Create Application" button, I get the page "Verify Your Account by SMS". I 
enter my phone number and back comes the message "*The phone number has 
been sent too many messages or has already been used to confirm an account.*
".

True, I have used it for setting up my account some time ago, but now I 
want to create a new application. My account IS verified.

So I feel stuck in a circle. I think I need help: 

How can I prevent the Verify page from appearing instead of some page for 
registering a new application?

Thanks in advance
Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/CEb_yY5O2MIJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: The Dining Philosophers

[Emlyn]

Germ of an idea:

Assume we can implement semaphore entirely in memcache, ignoring the
fact that it can be flushed.

Then, to cope with being flushed, we could have an idea of a Semaphore
as being in one of three states; Ok, Gone and Restarting.

Ok is just normal operation
Gone is when you know it's been flushed
You detect Gone by noticing the problem when you try to touch the
Semaphore (in Wait() and Signal() calls). You restart the Semaphore.
Restarting is a period where you are trying to get back to Ok state.

Basically, the idea will be that if the Semaphore disappears, we go
into a state (Restarting) where we are going to wait for a while until
we can know that the semaphore should be unused, then reset it to it's
initial state (ie: unused) and we're good to go again. The way we'll
do this is to wait a bit for anyone who might be using the semaphore
to finish, and then once we've waiting long enough, we just assume
everyone is done and proceed. It's a timeout, and it means imposing a
maximum time length on holding the Semaphore that callers need to
obey.

Semaphores have two bits of internal state which needs to be maintained:
- Counter
- Wait List

The Wait list really needs to be in the datastore, because if it gets
flushed there's just no way to reconstitute it, Waiters will be lost
forever.
But the counter has more promise.

Try an algorithm like this:

Semaphores only have two methods which need to accomodate these states:
Wait()
   Touch the semaphore. What state are we in?
   OK: Proceed as normal (if the counter is above zero then decrement
it and proceed, else suspend on the wait list)
   GONE: Reconstruct the semaphore in Restarting state. Suspend on the
wait list.
   RESTARTING: Suspend on the wait list.

Signal()
   Touch the semaphore. What state are we in?
   OK: Proceed as normal (if there is anyone on the wait list, awaken
one. Otherwise, just increment the counter)
   GONE: Reconstruct the semaphore in RESTARTING state. Increment the
counter. If it's equal to TokenMax, then Start the semaphore.
   RESTARTING: Increment the counter. If it's equal to TokenMax, then
Start the semaphore.

Semaphores are extended as follows:

A reconstructed Semaphore in RESTARTING state is initialised with Counter = 0.

We are going to restart the semaphore by
- defining a maximum length of time that a Semaphore token can be held
(if you're using Front End tasks, just set it longer than the maximum
task length).
- when we restart, we schedule a Start task for a time in the future
equal to the maximum task length.
- When the Start task runs, it checks the Semaphore. If it's still in
RESTARTING state, it Starts the Semaphore.
- There is an ABA problem here. A Start task is scheduled, the
Semaphore restarts before the task runs, then goes back into GONE and
RESTARTING again (and another Start task is kicked off), then the
original Start task runs and prematurely wakes the Semaphore. Fix this
by adding a StartTaskID (uuid) to the Semaphore, generate a new one
each time the Start Task runs, and pass it to the Start Task. An old
StartTask will have the wrong uuid and can terminate itself based on
that.

Start the Semaphore:
Either in the Start Task, or as the result of a Signal, we've
determined that it's ok to Start the semaphore. So set the Counter to
MaxCounter and change the state to OK. If there is anyone on the Wait
List, wake as many of them as the counter allows, decrementing the
counter for each one.

===

I think this approach can work, and the cool thing is that the counter
and the state should be implementable in Memcache. If the resource
you're using isn't normally under contention (very commonly this is
true, contention is unusual), then your most common operations will be
in Memcache and wont touch the datastore. This also assumes that cache
flushing is uncommon (if it flushed often, then it should still be
correct, but the performance will be poor, because the restarting
process is pretty slow). If the cache flushes really, really often
(sub second?) then you'll starve, but I don't think memcache does
that!

Any thoughts?

On 27 October 2011 23:24, Emlyn  wrote:
> Thanks, I had no idea that Memcache was so capable (I haven't looked
> closely enough recently). You could absolutely build a semaphore using
> those methods (cas would do the job nicely). Except of course that it
> could disappear at any moment. I can't help thinking that there must
> be some way to cope with that, however. Worth a ponder!
>
> On 27 October 2011 18:53, Murph  wrote:
>> I think it's basically possible to do locking, mutexes, semaphores, etc in
>> memcache, by taking advantage of some of the semantics, plus the new-ish
>> compare & store stuff.  There's the obvious caveat that it could be flushed
>> without warning, or disabled for a while, so it's not a high reliability
>> thing.
>>
>>   def add(self, key, value, time=0, min_compress_len=0, namespace=None):
>>     """Sets a key's value, iff item is not already

Re: [google-appengine] Discounted instance-hours commitment question

[Gregory D'alesandre]

Hi Jason, they apply after the free hours, so you should set 154 hours per
week in this example to achieve your intended goal.

Greg

On Thu, Oct 27, 2011 at 8:51 AM, Jason Collins wrote:

> The time is approaching when we need to configure our discounted
> instance-hours.
>
> Does the discount apply before or after the daily free quota is
> considered?
>
> By example:
>
> Imagine that my app uses 50 instance-hours per day, 28 of which are
> free.
> Weekly, I would use 350 instance-hours, though 196 of them are free.
>
> If I wanted to commit to the exact amount (to keep this example
> simple), should I commit to:
>
> (1) 350 hours per week, or
> (2) 350 - 196 = 154 hours per week
>
> ?
>
> Thanks,
> j
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: URGENT: memcache errors out on write, the entire site is down

[jon]

Johan no I didn't change the default error handler.

In our case memcache failed when executing putAll().

Are you confirming that this is currently a bug in the trunk (hence
1.5.5)?

It has a rather scary implication i.e. misbehaving memcache would take
down a site.

On Oct 27, 4:34 pm, Johan Euphrosine  wrote:
> After taking a closer look at the implementation, I found the method
> throwing the reported exception 
> (MemcacheServiceException):http://www.google.com/codesearch#Qx8E-7HUBTk/trunk/java/src/main/com/...
>
> It appears that it doesn't rely on getErrorHandler for routing errors
> and throws MemcacheServiceException directly.
>
> That should be pretty easy to verify using an unittest.
>
> Let me know if I missed something.
>
>
>
>
>
>
>
>
>
> On Thu, Oct 27, 2011 at 2:19 PM, Johan Euphrosine  wrote:
> > Jeff, you are right the default handler is supposed to handle both
> > DeserializationError and ServiceError:
> >http://code.google.com/p/googleappengine/source/browse/trunk/java/src...
>
> > Jon did you change the default memcache error handler ?
>
> > On Thu, Oct 27, 2011 at 1:37 PM, Jeff Schnitzer  wrote:
> >> Are you saying that we should not expect the
> >> MemcacheService.set/getErrorHandler(), with its default value of
> >> LogAndContinueErrorHandler, to do what it says?  I expect memcacheservice 
> >> to
> >> fail silently.
> >> Is it possible that the error handler showed up in 1.5.5?  The OP mentioned
> >> in another thread that he is running on 1.5.4.
> >> Jeff
> >> On Wed, Oct 26, 2011 at 5:12 PM, Johan Euphrosine  
> >> wrote:
>
> >>> Hi Jon,
>
> >>> It is important that you have proper exception handling for all your
> >>> API calls, as there is always a possibility of them failing (otherwise
> >>> we wouldn't document those methods as throwing an exception). In the
> >>> catch block you should usually fallback or retry gracefully: for
> >>> memcache it makes senses to fallback on datastore (more latency, but
> >>> more reliable).
>
> >>> In addition you can use the capabilities API to proactively query if a
> >>> given API is available, this is described in details by Nick Johnson
> >>> in the following blog  post:
>
> >>>http://blog.notdot.net/2010/03/Handling-downtime-The-capabilities-API...
>
> >>> Hope that helps.
>
> >>> On Thu, Oct 27, 2011 at 8:28 AM, jon  wrote:
> >>> > How did you fix/get around this problem?
>
> >>> > It was pointed out to me that the MemcacheService by default should
> >>> > *NOT* throw any exception, therefore what I was seeing is a bug.
>
> >>> > Can anyone from Google confirm if this is the case? I'm using 1.5.4.
>
> >>> > On Oct 26, 9:32 am, James Broberg  wrote:
> >>> >> Fair enough. At least you got a memcache exception :) In our case
> >>> >> performance just deteriorated and eventually it timed out.
>
> >>> >> On 26 October 2011 00:17, jon  wrote:
>
> >>> >> > Thanks James for pointing them out. They're not entirely identical in
> >>> >> > that the symptom is different (i.e. the exception I got is
> >>> >> > different).
> >>> >> > However there's a common pattern whereby an app seems to be assigned
> >>> >> > a
> >>> >> > memcache "service provider" and if this provider misbehaves the app
> >>> >> > will be stuck with it instead of getting reassigned a new, healthy
> >>> >> > replacement.
>
> >>> >> > On Oct 25, 11:26 pm, James Broberg  wrote:
> >>> >> >> Sounds familiar:
>
> >>> >> >> >>http://code.google.com/p/googleappengine/issues/detail?id=5790http://...
>
> >>> >> >> On 25 October 2011 20:16, jon  wrote:
>
> >>> >> >> > Memcache for our app is back now.
>
> >>> >> >> > According to the log, memcache write operations started throwing
> >>> >> >> > com.google.appengine.api.memcache.MemcacheServiceException at
> >>> >> >> > 17:49
> >>> >> >> > (Melbourne
> >>> >> >> > time) and stopped at 18:56. In other words memcache was
> >>> >> >> > unavailable
> >>> >> >> > for over 1
> >>> >> >> > hour.
>
> >>> >> >> > We use memcache heavily, so our site would've been down for that
> >>> >> >> > long
> >>> >> >> > if we
> >>> >> >> > hadn't stepped in to turn off all uses of memcache.
>
> >>> >> >> > Question for Google: is there an affinity between an app and it's
> >>> >> >> > memcache
> >>> >> >> > service provider? How can memcache consistently error out for the
> >>> >> >> > same
> >>> >> >> > application for that long?
>
> >>> >> >> > On Oct 25, 6:29 pm, jon  wrote:
> >>> >> >> >> Hi,
>
> >>> >> >> >> Writing to memcache is down for one of our apps, other apps are
> >>> >> >> >> OK.
>
> >>> >> >> >> The error message says:
> >>> >> >> >> java.lang.RuntimeException:
> >>> >> >> >> com.google.appengine.api.memcache.MemcacheServiceException:
> >>> >> >> >> Memcache
> >>> >> >> >> put: Set failed to set 20 keys
>
> >>> >> >> >> The affected app id: thecrowdvoice
>
> >>> >> >> >> Could someone from Google urgently take a look please?
>
> >>> >> >> >> Thanks in advance,
> >>> >> >> >> Jon
>
> >>> >> >> > --
> >>> >> >> > You received this message because

[google-appengine] Deploy drops data

[Phil McDonnell]

Twice now a deploy has cleared several of the data tables in my deployed
datastore.  Does anyone know what causes this?  The symptoms both times are
consistent.  I do a deploy and the datastore drops several of the tables.
 Strangely, one very old (and generally unused) table is not dropped and my
blob data is still there.  Is this dropping of data/tables  on deploy a
known "feature" that I'm somehow not understanding?  Note, this does not
happen on every deploy.

We are still pre-launch, but I'm extremely concerned that this could happen
when we are live.  If we drop our data when we are live it would cost us a
lot of money.

Thanks so much,
Phil

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Design Question - How to simulate efficient joins

[Jose Montes de Oca]

On Thursday, October 27, 2011 1:06:16 PM UTC-7, Jeff Schnitzer wrote:
>
> I'm going to be the dissenting here.  You should consider #1 if you know 
> that you're always going to have on the order of 100 items.  You can easily 
> cache this value in memcache.


IMO this would depend on the size of the items, fetching 100 items and 
then traversing then to do a simple sum could be a great overhead on read 
time that could be avoid by doing this on write time. (This is App Engine 
strategy for queries)

 

>
> When you get into thousands of items you start to see the point at which 
> it's not practical to do on-the-fly sums, even just to store the result in 
> memcache.  But less than thousands, might as well just calculate the sum.
>
> Pre-aggregating the sum is not necessarily trivial.  If the sum changes 
> more than once per second you need to shard the sum.  Once you get to 100 
> shards, you've created a system that doesn't perform any better and is a 
> hell of a lot more complicated.
>
> One thing to watch out for is eventuality - if your sum needs to be 
> instantaneously correct, a simple query (on the HRD) may provide lagged 
> data.  On the other hand, if you are fetching your articles by key (and 
> have STRONG consistency configured), you're ok.
>

If you do an ancestor query you will get consistent data. 


> Jeff
>
> On Thu, Oct 27, 2011 at 12:49 PM, Jose Montes de Oca  > wrote:
>
>> Hi Mos,
>>
>> You should design your data models as a non relational database, where 
>> having redundancy its just fine. 
>>
>> Plain and simple:
>>
>> 1/ will not scale, Not suitable for App Engine non relational database 
>> (Datastore)
>>
>> 2/ Right Approach, just need to be careful on what voscausa said. 
>>
>> Hope this helps!
>>
>> Jose Montes de Oca
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/google-appengine/-/sUbapsIqigAJ.
>>
>> To post to this group, send email to google-a...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> google-appengi...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/IPbmPDCItzYJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Design Question - How to simulate efficient joins

[Jeff Schnitzer]

I'm going to be the dissenting here.  You should consider #1 if you know
that you're always going to have on the order of 100 items.  You can easily
cache this value in memcache.

When you get into thousands of items you start to see the point at which
it's not practical to do on-the-fly sums, even just to store the result in
memcache.  But less than thousands, might as well just calculate the sum.

Pre-aggregating the sum is not necessarily trivial.  If the sum changes more
than once per second you need to shard the sum.  Once you get to 100 shards,
you've created a system that doesn't perform any better and is a hell of a
lot more complicated.

One thing to watch out for is eventuality - if your sum needs to be
instantaneously correct, a simple query (on the HRD) may provide lagged
data.  On the other hand, if you are fetching your articles by key (and have
STRONG consistency configured), you're ok.

Jeff

On Thu, Oct 27, 2011 at 12:49 PM, Jose Montes de Oca <
jfmontesde...@google.com> wrote:

> Hi Mos,
>
> You should design your data models as a non relational database, where
> having redundancy its just fine.
>
> Plain and simple:
>
> 1/ will not scale, Not suitable for App Engine non relational database
> (Datastore)
>
> 2/ Right Approach, just need to be careful on what voscausa said.
>
> Hope this helps!
>
> Jose Montes de Oca
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/sUbapsIqigAJ.
>
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Design Question - How to simulate efficient joins

[Jose Montes de Oca]

Hi Mos,

You should design your data models as a non relational database, where 
having redundancy its just fine. 

Plain and simple:

1/ will not scale, Not suitable for App Engine non relational database 
(Datastore)

2/ Right Approach, just need to be careful on what voscausa said. 

Hope this helps!

Jose Montes de Oca

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/sUbapsIqigAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] XMPP authentication

[Paul G]

I am looking to use the XMPP service as a form of 'broadcast push' to
authenticated users of the app...

ie when content changes on the backend the server would post a message
to a group chat

front-end clients would be listening (I guess via strophe.js) to
particular group chats

This seems more efficient than the Channel API where I'd have to
maintain a channel per user, even though there are no user-specific
messages that need to be sent, only broadcast changes to all users.

But... the docs are completely unclear on how I would authenticate
users, i.e. prevent unauthorised users to listening to the updates
chatroom.

>From what little I've read XMPP has TLS and SASL for this purpose but
I can't find anything written about those in conjunction with GAE.
>From messages on this list it sounds like I'd in fact need a whole
other XMPP server to manage user accounts... or... it's completely
unclear basically.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: blobstore file

[Jason Collins]

Yes. http://code.google.com/p/googleappengine/issues/detail?id=4944


On Oct 26, 3:29 pm, Mark Jen  wrote:
> Hi,
>
> I've run into a problem using the file API for blobstore
> (http://code.google.com/appengine/docs/python/blobstore/overview.html#...) on
> dev_appserver.py with --high_replication. It seems that after
> files.finalize(file_name) is called, the blob_key is not immediately
> available. Is this a known issue? I couldn't find it here
> (http://code.google.com/p/googleappengine/issues/list).
>
> Thanks,
> Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Discounted instance-hours commitment question

[Jason Collins]

The time is approaching when we need to configure our discounted
instance-hours.

Does the discount apply before or after the daily free quota is
considered?

By example:

Imagine that my app uses 50 instance-hours per day, 28 of which are
free.
Weekly, I would use 350 instance-hours, though 196 of them are free.

If I wanted to commit to the exact amount (to keep this example
simple), should I commit to:

(1) 350 hours per week, or
(2) 350 - 196 = 154 hours per week

?

Thanks,
j

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: URGENT: memcache errors out on write, the entire site is down

[Simon Knott]

Now that I've got some caffeine in my system, I'll correct myself - it 
looks like the error handler isn't used for "put" operations at all and 
it's possible that individual increment calls with fail non-silently as 
well.  The rest of the calls either use the error handler correctly, or 
just fail silently anyway.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/wqNb9L1OX4cJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] URLFetch is timing out excessively

[Nischal Shetty]

Twitter has fixed the connectivity issues.

On 26 October 2011 20:07, Nischal Shetty  wrote:

> Yeah, you are right about that. I had faced it a few months ago following
> which I moved that part to AWS. The other API calls though in excess are
> below those variable limits.
>
> I got a reply by twitter on their discussion forum that they are looking
> into the issue. Hoping they find the cause soon.
>
>
> On 26 October 2011 20:01, Brandon Wirtz  wrote:
>
>> Signed calls are still subject to a variable rate limit based on Twitters
>> given load. They throttle up and down based on available capacity.
>>
>> ** **
>>
>> ** **
>>
>> *From:* google-appengine@googlegroups.com [mailto:
>> google-appengine@googlegroups.com] *On Behalf Of *Nischal Shetty
>> *Sent:* Wednesday, October 26, 2011 2:47 PM
>>
>> *To:* google-appengine@googlegroups.com
>> *Subject:* Re: [google-appengine] URLFetch is timing out excessively
>>
>> ** **
>>
>> It works from a non google environment. We have a service running on AWS
>> which is working smooth. It's not a whitelist problem because these are
>> signed calls which do not account for rate limiting based on IP.
>>
>> ** **
>>
>> Someone from google has replied saying the problem is not on their end. I
>> have raised an issue on the twitter discussion forum (stupid of me to not
>> have done that simultaneously). 
>>
>> ** **
>>
>> ** **
>>
>> On 26 October 2011 18:33, Brandon Wirtz  wrote:
>>
>> So you think that Fetches to only Twitter and FB are broken?   Did you try
>> from a non-Goog Environment?  There are Fail Whales all over today.   ***
>> *
>>
>>  
>>
>> And if you are running “Hundreds of API calls a minute” you are likely
>> hitting the API IP Limits since Twitter won’t grant a white list for Google
>> IP’s.
>>
>>  
>>
>> You should be using a proxy to access twitter through a single IP what is
>> on the Twitter API white List.
>>
>>  
>>
>>  
>>
>> *From:* google-appengine@googlegroups.com [mailto:
>> google-appengine@googlegroups.com] *On Behalf Of *nischalshetty
>> *Sent:* Wednesday, October 26, 2011 12:11 PM
>> *To:* google-appengine@googlegroups.com
>> *Subject:* Re: [google-appengine] URLFetch is timing out excessively
>>
>>  
>>
>> I agree twitter times out but this is not because of them. I'm talking
>> about hundreds of timeout every minute.
>>
>>  
>>
>> We have things in place to retry timeouts, but I'm talkin about timeouts
>> even after 3 retries with a timeout of 20 second each. 
>>
>>  
>>
>>  
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/google-appengine/-/YJ2bm0bM_l8J.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>>
>>
>> 
>>
>> ** **
>>
>> --
>> -Nischal
>>
>> twitter: NischalShetty 
>>
>> facebook: Nischal 
>>
>> ** **
>>
>> [image: Description: Image removed by sender.]
>>   [image: Description: Image removed by sender.] *
>> ***
>>
>> ** **
>>
>> ** **
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
>
>
> --
> -Nischal
> twitter: NischalShetty 
> facebook: Nischal 
>
>  
>
>
>


-- 
-Nischal
twitter: NischalShetty 
facebook: Nischal 

 

Re: [google-appengine] Re: Emails sent from GAE apps to yahoo or hotmail addresses get tagged as spam

[Barry Hunter]

On Thu, Oct 27, 2011 at 2:07 AM, Greg  wrote:
> On Oct 27, 12:45 am, Joshua Smith  wrote:

>
> I'm about to move to SMS verification because if Google does it, it's
> likely the best solution.

I think the reason google do it is to manage people signing up for
multiple accounts (lots of incentive with the generous free quota) -
its a lot harder to get lots of disposable mobile numbers, than it is
to get another email address.

It doesnt  'verify' the email as such, so still subject to typos etc.
It does however help with fighting spambots...


(and search this group for links to the sms waitlist form. Lots of
people obvisoully fail to pass sms validation)





>
> Cheers
> Greg.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Emails sent from GAE apps to yahoo or hotmail addresses get tagged as spam

[Joshua Smith]

I've never seen subject= fail.  However, it occurs to me that people who use 
web clients to do their email (many gmail users, in particular) will probably 
not be able to handle mailto: urls correctly, right? It will probably open 
outlook express or something, which will probably not be configured correctly.

On Oct 26, 2011, at 9:07 PM, Greg wrote:

> On Oct 27, 12:45 am, Joshua Smith  wrote:
>> mailto:regis...@myapp.appspotmail.com?subject=a9b8c7d6e5f
> 
> How bulletproof is the subject in a mailto: URL? I tried it years ago,
> and many email clients ignored it completely.
> 
> I'm about to move to SMS verification because if Google does it, it's
> likely the best solution.
> 
> Cheers
> Greg.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: The Dining Philosophers

[Emlyn]

Thanks, I had no idea that Memcache was so capable (I haven't looked
closely enough recently). You could absolutely build a semaphore using
those methods (cas would do the job nicely). Except of course that it
could disappear at any moment. I can't help thinking that there must
be some way to cope with that, however. Worth a ponder!

On 27 October 2011 18:53, Murph  wrote:
> I think it's basically possible to do locking, mutexes, semaphores, etc in
> memcache, by taking advantage of some of the semantics, plus the new-ish
> compare & store stuff.  There's the obvious caveat that it could be flushed
> without warning, or disabled for a while, so it's not a high reliability
> thing.
>
>   def add(self, key, value, time=0, min_compress_len=0, namespace=None):
>     """Sets a key's value, iff item is not already in memcache.
>
>   def replace(self, key, value, time=0, min_compress_len=0, namespace=None):
>     """Replaces a key's value, failing if item isn't already in memcache.
>
>   def cas(self, key, value, time=0, min_compress_len=0, namespace=None):
>     """Compare-And-Set update.
>
>   def incr(self, key, delta=1, namespace=None, initial_value=None):
>     """Atomically increments a key's value.
>
>   def decr(self, key, delta=1, namespace=None, initial_value=None):
>     """Atomically decrements a key's value.
>
> It seems to me the you could carefully use the above in various creative
> ways to implement this, if you require frequent use and the datastore costs
> would be prohibitive for it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/cAlYR6jxlogJ.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>



-- 
Emlyn

http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google
Buzz posts,
comments and all.
http://point7.wordpress.com - My blog
Find me on Facebook and Buzz

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: URGENT: memcache errors out on write, the entire site is down

[Simon Knott]

Looking at that code for the MemcacheService implementations, the error 
handler isn't used at all!

My code is currently written to depend on the ErrorHandler allowing the 
service to fail silently - it would be great if you could confirm one way 
or another whether the error handlers are now useless.

Cheers,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/XYcKR2xFHQkJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: URGENT: memcache errors out on write, the entire site is down

[Simon Knott]

Sorry Johan, so are you confirming that this is a bug in the Memcache 
Service?

The JavaDoc for the handleServiceError method on ErrorHandler quite clearly 
states that this method will be called for *all *MemcacheService methods in 
the event of a service error.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/27aM-MoL_bgJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: The Dining Philosophers

[Murph]

I think it's basically possible to do locking, mutexes, semaphores, etc in 
memcache, by taking advantage of some of the semantics, plus the new-ish 
compare & store stuff.  There's the obvious caveat that it could be flushed 
without warning, or disabled for a while, so it's not a high reliability 
thing.

  def add(self, key, value, time=0, min_compress_len=0, namespace=None):
"""Sets a key's value, iff item is not already in memcache.

  def replace(self, key, value, time=0, min_compress_len=0, namespace=None):
"""Replaces a key's value, failing if item isn't already in memcache.

  def cas(self, key, value, time=0, min_compress_len=0, namespace=None):
"""Compare-And-Set update.

  def incr(self, key, delta=1, namespace=None, initial_value=None):
"""Atomically increments a key's value.

  def decr(self, key, delta=1, namespace=None, initial_value=None):
"""Atomically decrements a key's value.

It seems to me the you could carefully use the above in various creative 
ways to implement this, if you require frequent use and the datastore costs 
would be prohibitive for it.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/cAlYR6jxlogJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Inactive Instances

[Sun Jing]

Those idle instance won't be charged. You can check the Billed curve
of the Instances
chart in your app's Dashboard.

--
keakon

My blog(Chinese): www.keakon.net
Blog source code: https://bitbucket.org/keakon/doodle/



On Thu, Oct 27, 2011 at 2:37 PM, PanosJee  wrote:

> Hi everyone,
> My app is currently using 8 instances. 3 of them have 0 QPS and they live
> for over 8 hours. Has the scheduler any issues and is not killing old
> instances? I am afraid it will take a toll on my app once the new pricing in
> enabled.
>
> 1.933126.9 ms17600:01:2638.3 MBytes[image: Dynamic Icon]Dynamic1.050124.8
> ms6200:00:2829.9 MBytes[image: Dynamic Icon]Dynamic0.533226.1 ms3100:00:2733.1
> MBytes[image: Dynamic Icon]Dynamic3.55085.6 ms82200:04:2839.1 MBytes[image:
> Dynamic Icon]Dynamic0..0 ms2608:31:1921.0 MBytes[image: Dynamic Icon]
> Dynamic0..0 ms1407:16:5917.2 MBytes[image: Dynamic Icon]Dynamic0..0
> ms67
> 010:59:3129.6 MBytes[image: Dynamic Icon]Dynamic
>
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/wCKJRIX3cLQJ.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.