Re: [google-appengine] Re: Backend performance, compared

[Takashi Matsuo]

First of all, thank you for the detailed cost comparison and the
honest feedback. We really appreciate it.

The data itself is not very far from what I observed in my test.
Certainly, we should try making the backends cheaper. The easiest fix
will be this issue:
http://code.google.com/p/googleappengine/issues/detail?id=7411

It will reduce the cost by 5/8(if the discount rate is the same as the
one for frontend), so it'll be $360/month for 10 B1s.

Besides the cost, we should also improve the performance itself.

You might say 'It's still insane', however, I don't think so, because
App Engine backends provides other goodies like high availability,
redundancy, maintenance-free nature from the start.

Please think this way. Would you like to offer a score-server service
for Richard by yourself at a cost of $360/month? Besides running a
single node.js server, you also need to run a spare server, need to
create a monitoring/fail-over mechanism, need to have a support
channel when in trouble, and sometimes need to diagnose any network
problem between App Engine and your server.

If the answer is yes, probably it's a good business chance for you ;)

I'm not saying that App Engine is perfect, but i just wanted to point
out that your comparison lacks(maybe it's intentional) a consideration
for the important aspects of App Engine.

However, your feedback is still invaluable to us. Thank you as always.

Regards,

-- Takashi


On Thu, Aug 9, 2012 at 3:31 PM, Jeff Schnitzer  wrote:
> On Wed, Aug 8, 2012 at 11:01 PM, Kristopher Giesing
>  wrote:
>> Do we know for sure that front ends are any faster?  Their individual
>> throughput limits might just be masked by having more of them spin up.
>
> I expect frontends are about the same.  But frontends can't aggregate
> scores so they aren't really an issue in this test.  If you want to
> feel even worse for Richard, he's paying for what seems like an
> unreasonable number of F1 instances too... but for some reason that
> seems less frustrating than the totally unnecessary need to add a
> second equivalent number of backends.
>
> 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.
>



-- 
Takashi Matsuo | Developer Advocate | tmat...@google.com

-- 
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] How can I block curl requests

[sergey]

Can you show what you have in log for curl requests?

On Thursday, August 9, 2012 6:17:32 AM UTC+3, Kate wrote:
>
> My site is now down as I'm  over quota. I can't tun billing on as it is 
> too expensive to pay for these dos attacks.
>
> Thanks everyone for being helpful but I think I'm beaten on this. It seems 
> a pity that a non profit site could be brought down by this but that's the 
> case.
> Google doesn't seem to care as there has been no response on my production 
> issue. I suppose it isn't in their interest as I either pay for the attacks 
> or lose my site. V discouraging.
>
> All attempts at blocking the attacks has only increased their volume.
>
> Kate
>
>
>
>
> On Wednesday, August 8, 2012 1:24:36 PM UTC-4, Kyle Finley wrote:
>>
>> In the admin logs - under options - you can filter by regular expression. 
>> Does that help? 
>>
>> On Aug 8, 2012, at 12:11 PM, Kate wrote: 
>>
>> > It isn't stopping them. I am just not getting errors. What is troubling 
>> is that these curl requests are counting as hits and there are so many of 
>> tens of thousands of them it is hard for me to analyze site traffic as 
>> genuine requests are buried in the curl stats. 
>> > 
>> > -- 
>> > 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/-/p4fPoQaAACIJ. 
>> > 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/-/-9sJd7OlrQ0J.
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] Entity relationship, owned or unowned, is always dependent

[Tobiáš Potoček]

I use current latest SDK (version 1.7.0) and for accessing the datastore I use 
JDO 3.0 and DataNucleus Plugin 2.0 (everything provided by the SDK, nothing 
external).

According to the documentation, an owned relationship can be "dependent" but in 
my case, the relationship is always dependent, meaning that child objects are 
always deleted with parent object. I tried to use @Element(dependent = 
"false"), but it had no effect. 

The same problem applies to unowned relationships. They are always dependent. 
There is a little difference though.

When removing an object from the collection by calling .remove( ), the object 
is always deleted from the datastore for both owned and unowned relationship. 
However when I call .clear() on the collection, for unowned relationships, the 
objects are kept in the datastore. For owned relationships they are deleted.

I tried to deploy the application but the behavior is the same when running on 
Google servers.

I posted this question on StackOverflow, but they just told me to read the 
documentation. I also filed an issue for AppEngine in case it was really a bug, 
but I don't think so, using relationships is a big thing, some would have 
noticed. I guess I'm just doing something wrong, but I have no idea what. 
Please I would appreciate any help. 

-- 
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/-/pEh3qHmFzIIJ.
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] Entity relationship, owned or unowned, is always dependent

[Tobiáš Potoček]

I use current latest SDK (version 1.7.0) and for accessing the datastore I 
use JDO 3.0 and DataNucleus Plugin 2.0 (everything provided by the SDK, 
nothing external).\

According to the documentation, an owned relationship can be "dependent" 
but in my case, the relationship is always dependent, meaning that child 
objects are always deleted with parent object. I tried to use 
@Element(dependent = "false"), but it had no effect.

The same problem applies to unowned relationships. They are always 
dependent. There is a little difference though. When removing an object 
from the collection by calling .remove( ), the object is always deleted 
from the datastore for both owned and unowned relationship. However when I 
call .clear() on the collection, for unowned relationships, the objects are 
kept in the datastore. For owned relationships they are deleted. I tried to 
deploy the application but the behavior is the same when running on Google 
servers.

I posted this question on StackOverflow, but they just told me to read the 
documentation. I also filed an issue for AppEngine in case it was really a 
bug, but I don't think so, using relationships is a big thing, some would 
have noticed. I guess I'm just doing something wrong, but I have no idea 
what. Please I would appreciate any help. 

-- 
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/-/iDTNON-nMxoJ.
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: The Data Collection for Game Question

[alex]

I think you meant XMPP (though Channels API are indeed based on XMPP). 
As Kris mentioned, Channel client is available only in JS whereas XMPP is 
for a server side (i.e. what you probably need).


On Wednesday, August 8, 2012 7:47:09 PM UTC+2, Brandon Wirtz wrote:
>
> I don’t have time to build a solution write now, because we are too close 
> to our own product launch, but in thinking about this I wondered about 
> Channel API between servers….
>
>  
>
> This is a solution I have been thinking about and if someone knows why it 
> won’t work that might save me some headache or might reduce theirs if it 
> works.
>
>  
>
> Could you not have frontends use the channel API to send the data to the 
> backend.  The data would be streamed to the backend and the buffer in the 
> channel would allow the backend to read the stream of data in to its 
> memory. The calculations could be done, and then written to datastore and 
> memcache so that when the client re-polled the scores would be correct and 
> shared?
>
>  
>
>  
>

-- 
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/-/eE2LRwWIDeQJ.
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: G+ hangout on Wed., 8th Aug., at 4pm PDT - Cloud Endpoints

[alex]

Hey Amy,

thanks for a nice wrap up on Endpoints API to you and Dan but I think you 
would have had a lot more participation if 
(1) docs were published (for all supported runtimes); and 
(2) larger trusted testers group. 

Otherwise, it goes something like "you can look but you can't touch this".

-- alex

On Wednesday, August 8, 2012 10:58:03 PM UTC+2, Amy Unruh wrote:
>
> Reminder: join us today for a G+ hangout on Cloud Endpoints, Wed. 4pm PDT.
>
> https://developers.google.com/live/shows/ahNzfmdvb2dsZS1kZXZlbG9wZXJzcg4LEgVFdmVudBjAjqkDDA/
>
> On 7 August 2012 09:40, Amy Unruh >wrote:
>
>> There will be an App Engine G+ hangout on Wed., 8th Aug., at 4pm Pacific 
>> time (23:00 UTC).
>>
>> This week's App Engine Hangout will include a demonstration of using 
>> Java, OAuth 2, and JS with Cloud Endpoints, with plenty of time for 
>> discussion.
>>
>> Visit this event to find the hangout when it starts up: 
>>
>> https://developers.google.com/live/shows/ahNzfmdvb2dsZS1kZXZlbG9wZXJzcg4LEgVFdmVudBjAjqkDDA/
>> Submit questions via Google Moderator: 
>> https://www.google.com/moderator/#15/e=1faeac&t=1faeac.48
>>
>> Find out when the hangout starts in your time zone: http://goo.gl/vDcuv
>>
>> Subscribe to calendar events for these hangouts here: http://goo.gl/GGkgx, 
>> http://goo.gl/PILq0 .
>>
>> Hope you can join us!
>>
>
>

-- 
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/-/xM-Fy_0CyqYJ.
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: Backend performance, compared

[Johan Euphrosine]

On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer  wrote:

> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla  wrote:
> > Thanks, Jeff. Is it possible to repeat the test with qps < 10 to rule out
> > the limit that Johan pointed out? In other words, how big is the
> performance
> > difference if you had less requests that do more work?
>
> You must mean concurrency less than 10?
>
> I'm not really certain how concurrency relates to this.  All the tests
> I ran (Node.js, Twisted, Tornado, Simple) were nonblocking servers
> with a concurrency of 1.



Actually those server/framework do support processing multiple request
concurrently, when one of the request handler/callback is doing I/O it can
process another request. (Just like the go backend I tested)
They just don't do parallelism (by default).



>  Maybe - just maybe - it would be possible to
> increase throughput by using multiple system threads up to the number
> of cores available... but then you would lose performance due to
> synchronization.  Probably significantly.  Optimal hardware
> utilization is one isolated, single-threaded, nonblocking server per
> core.
>
> I really don't know why backends are slow.  Maybe it has something to
> do with the request queueing system?  Throughput sucks even when
> backends are doing noops.  Maybe "increased concurrency" would allow
> more requests to travel through the queueing system at once... but
> it's hard to imagine this helping out the actual server process at
> all.


Increasing concurrency could help if you are I/O bound, but it will not
help if you are truly CPU bound.

For a truly cpu-bound request, you are using as much cpu as the instance
class limit allows for all backends < B8, and half of the CPU limit for B8.
So with threadsafe: true, you can only process:
- 1 cpu bound request at a time on B1 B2 B4
- 2 cpu bound request at a time on B8

If you are not completely CPU bound and idling between CPU burst then
increasing concurrency would help, just like if you were bound on I/O
operations.

Hope that clarify the situation a bit.


>  More timeslicing and synchronization on a cpu- and memory-bound
> problem will reduce performance, not improve it.
>
> 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.
>
>


-- 
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.

[google-appengine] Re: Low hitting site experiencing denial of service attack - site opffline!

[Ernesto Oltra]

Have you tried CloudFlare? It's basically the same, a proxy to your app, 
and you don't have to make/admin it. It has a reputation system, and some 
others pretty good settings to deal with DOS attacks.

BTW, I'm not affiliated at all with the company, I'm only other web dev.

On Thursday, August 9, 2012 5:12:17 AM UTC+2, Kate wrote:
>
> My site has been on GAE for several years but am now experiencing denial 
> of service attacks. I don't want to pay for them so my site is now down. I 
> put in a production issue last week and have tried blocking the user agent 
> (curl). But I can't block by IP as all IPs are different.
>
> Apart from moving from GAE what can  I do.
>
> Thanks in advance,
>
> Kate
>
>

-- 
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/-/X__ET6dGR2wJ.
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

I made a cloudflare account but it can't resolve my domain name, 
www.australiansabroad.com as I don't have a dns entry at network solutions.com 
where I register my sites. I have a special entry that google resolves. And if 
I put in my appspot site name cloudflare says it cannot accept that.

-- 
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/-/UfV1hfuhhs8J.
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

I will have a go and then I will have to give up on google apps. I am very 
surprised they allow dos attacks. No web provider has allowed this to happen 
before.

-- 
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/-/0RfQ_4DZg3oJ.
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] How can I block curl requests

[Kate]

Hi Sergey,

Here is a typical example
2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 (i386-redhat-linux-gnu) 
libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18
202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 153 - 
"curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
libidn/0.6.14 libssh2/0.18" "aussieclouds.appspot.com" ms=31 cpu_ms=0 
api_cpu_ms=0 cpm_usd=0.49 instance=00c61b117c2f994812ed63184c9c5544dea738

But the ip address varies. My code forces 302 response. Before I added the code 
they were throwing errors head method not found. But even though I am doing the 
303 I am still getting front end time exceeded and these requests are taking up 
about 95% of my quota. So to keep the site alive I would have to pay for them, 
I have lost most of my European and Australian visitors because the site is 
down every night during those places daylight hours. Obviously I can't continue 
like this and so will have to move to a provider capable of blocking these 
requests,

-- 
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/-/tC4bapnRFMAJ.
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] How can I block curl requests

[Kate]

Hi Sergey,

Here is a typical example
2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 (i386-redhat-linux-gnu) 
libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18
202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 153 - 
"curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
libidn/0.6.14 libssh2/0.18" "aussieclouds.appspot.com" ms=31 cpu_ms=0 
api_cpu_ms=0 cpm_usd=0.49 instance=00c61b117c2f994812ed63184c9c5544dea738

But the ip address varies. My code forces 302 response. Before I added the code 
they were throwing errors head method not found. But even though I am doing the 
303 I am still getting front end time exceeded and these requests are taking up 
about 95% of my quota. So to keep the site alive I would have to pay for them, 
I have lost most of my European and Australian visitors because the site is 
down every night during those places daylight hours. Obviously I can't continue 
like this and so will have to move to a provider capable of blocking these 
requests,

-- 
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/-/MHFuAqELNlEJ.
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] How can I block curl requests

[Kate]

No cloudfare requires ands info which I do not have. 

I made a cloudflare account but it can't resolve my domain name, 
www.australiansabroad.com as I don't have a dns entry at network solutions.com 
where I register my sites. I have a special entry that google resolves. And if 
I put in my appspot site name cloudflare says it cannot accept that.


-- 
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/-/_O6arbPIFb8J.
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: Low hitting site experiencing denial of service attack - site opffline!

[Barry Hunter]

On Thu, Aug 9, 2012 at 12:48 PM, Kate  wrote:

> I will have a go and then I will have to give up on google apps. I am very
> surprised they allow dos attacks. No web provider has allowed this to
> happen before.
>

You probably have just been lucky. ddos attacks are actully pretty rare, so
its never been an issue before. Very  few providers are proactive about
blocking. Many will just throw you out (sadly).


The design of AppEngine, does make it hard to block the requests before
hitting instances. On other providers maybe could of used something like
rewrite rules to block them before they hit dynamic instances (like php).
But also the different way of paying (many providers only charge for
bandwidth and/or requests) means the instance time adds up, which woudlnt
be a problem elsewhere.


Something not sure if been mentioned before is Google do have a means to
contact them to be reimbused for changes assocated with a DOS
https://developers.google.com/appengine/kb/billing#dos

Have you tried that?



One final thing, it might not actully be a deliberate dos. It might just be
a misbehavioed crawler. Its getting stuck in a loop, on your error messages
- it doesnt expect a HEAD to fail, so its just retrying. Hence the
suggestion to actully handle head requests in the first place. (although at
the time didnt appreciate how many of these requests you getting) Turning
them into 200 OK, might cause them to go away satisfied.


Couple it with Cache-Control headers, to allow the Google edge cache to
cache the requests, means the edgecache might be able to forfil the
requests without touching dynamic instances.





>
> --
> 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/-/0RfQ_4DZg3oJ.
> 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] How can I block curl requests

[Barry Hunter]

Another thing, have you tried contacting PlanetLab themselves? (the ips
you've posted so far have come from them)

Researchers using the PlanetLab network are bound by an Acceptable Use
Policy  which forbids malicious or
disruptive behavior. Additionally, all PlanetLab nodes are secured and
actively managed  by the PlanetLab
Operations team.

If you are unable to determine the source of the traffic, please contact
PlanetLab Support (supp...@planet-lab.org). Feel free to direct any
additional concerns or questions about PlanetLab to this address.

-- 
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

I tried sending back a 302 when I get a head request and that didn't help.  All 
the ips asre different and not all come from planet lab. But I will contact 
planet lab. You would think they would stop however anyway as my site is down 
about 1/8th of the day now.

I will try the suggestions to date and if that doesn't work will seek out a new 
provider or just rename the site and get a new ip. I don't think it is planet 
lab looping as why would they keep changing the ip address? 

I googled the problem and most people suggest getting the provider to help but 
google isn't interested as they have nothing to gain.

I can ask new providers their policy before inning up. 

I did find another person on GAE with an identical problem but apparently he 
gave up.

Today I am already in to 20% of my quota and will soon lose. My only 
advertiser. I have already lost one, and my Adsense revenue is right down 
because of all the downtime.

I also use other google services not related to this site being attacked so if 
no resolution I will vote with my feet.


-- 
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/-/OSxYXB57MkkJ.
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

I tried sending back a 302 when I get a head request and that didn't help.  All 
the ips asre different and not all come from planet lab. But I will contact 
planet lab. You would think they would stop however anyway as my site is down 
about 1/8th of the day now.

I will try the suggestions to date and if that doesn't work will seek out a new 
provider or just rename the site and get a new ip. I don't think it is planet 
lab looping as why would they keep changing the ip address? 

I googled the problem and most people suggest getting the provider to help but 
google isn't interested as they have nothing to gain.

I can ask new providers their policy before inning up. 

I did find another person on GAE with an identical problem but apparently he 
gave up.

Today I am already in to 20% of my quota and will soon lose. My only 
advertiser. I have already lost one, and my Adsense revenue is right down 
because of all the downtime.

I also use other google services not related to this site being attacked so if 
no resolution I will vote with my feet.


-- 
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/-/2Bk3u1tVsmsJ.
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: Backend performance, compared

[Johan Euphrosine]

I just answered a question on the same topic on Stack Overflow:
http://stackoverflow.com/a/11882719/656408



On Thu, Aug 9, 2012 at 12:31 PM, Johan Euphrosine  wrote:

>
>
>
> On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer wrote:
>
>> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla  wrote:
>> > Thanks, Jeff. Is it possible to repeat the test with qps < 10 to rule
>> out
>> > the limit that Johan pointed out? In other words, how big is the
>> performance
>> > difference if you had less requests that do more work?
>>
>> You must mean concurrency less than 10?
>>
>> I'm not really certain how concurrency relates to this.  All the tests
>> I ran (Node.js, Twisted, Tornado, Simple) were nonblocking servers
>> with a concurrency of 1.
>
>
> 
> Actually those server/framework do support processing multiple request
> concurrently, when one of the request handler/callback is doing I/O it can
> process another request. (Just like the go backend I tested)
> They just don't do parallelism (by default).
> 
>
>
>>  Maybe - just maybe - it would be possible to
>> increase throughput by using multiple system threads up to the number
>> of cores available... but then you would lose performance due to
>> synchronization.  Probably significantly.  Optimal hardware
>> utilization is one isolated, single-threaded, nonblocking server per
>> core.
>>
>> I really don't know why backends are slow.  Maybe it has something to
>> do with the request queueing system?  Throughput sucks even when
>> backends are doing noops.  Maybe "increased concurrency" would allow
>> more requests to travel through the queueing system at once... but
>> it's hard to imagine this helping out the actual server process at
>> all.
>
>
> Increasing concurrency could help if you are I/O bound, but it will not
> help if you are truly CPU bound.
>
> For a truly cpu-bound request, you are using as much cpu as the instance
> class limit allows for all backends < B8, and half of the CPU limit for B8.
> So with threadsafe: true, you can only process:
> - 1 cpu bound request at a time on B1 B2 B4
> - 2 cpu bound request at a time on B8
>
> If you are not completely CPU bound and idling between CPU burst then
> increasing concurrency would help, just like if you were bound on I/O
> operations.
>
> Hope that clarify the situation a bit.
>
>
>>  More timeslicing and synchronization on a cpu- and memory-bound
>> problem will reduce performance, not improve it.
>>
>> 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.
>>
>>
>
>
> --
> Johan Euphrosine (proppy)
> Developer Programs Engineer
> Google Developer Relations
>



-- 
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: Low hitting site experiencing denial of service attack - site opffline!

[Jeff Schnitzer]

Someone else asked this, but I'll ask it again - have you tried using
CloudFlare?  Seems like this is what they are supposed to be for.  I'd
like to know if it works.

Google can't magically make your DDOS go away.  I don't know of any
hosting providers that can.  You need to use some sort of filtering
service like CF to handle it - there are several, but I gather most
are fairly expensive.  At least CF is free.

Sorry, but this is just the reality of the internet.  Moving off of
GAE might produce a somewhat cheaper solution, but it won't solve your
DDOS problem if your attacker is paying any attention.

Jeff

On Wed, Aug 8, 2012 at 10:06 PM, Kate  wrote:
> I don't know how to write the node.js. I am surprised that google cannot help 
> me here. I do appreciate your help but I just can't do this without spending 
> hours of study. To answer your other question, the blocking attempt didn't 
> solve the problem. The curl requests come about 3 times per  second. I have 
> been working on trying to stop them for over a week now. I suppose I can just 
> change my domain name or move to another hosting service but it seems a pity.
>
> I have had this site since 1996 with never a problem.
>
> --
> 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/-/RLTiLlM5cTsJ.
> 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: Backend performance, compared

[Jeff Schnitzer]

I think I mentioned this before, but there is no I/O in the problem.
It just collects data in RAM (thousands of individual submissions) and
waits for the reaper come get the entire set in one fetch.  This is
why I do not expect concurrency to help.

Jeff

On Thu, Aug 9, 2012 at 3:31 AM, Johan Euphrosine  wrote:
>
>
>
> On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer  wrote:
>>
>> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla  wrote:
>> > Thanks, Jeff. Is it possible to repeat the test with qps < 10 to rule
>> > out
>> > the limit that Johan pointed out? In other words, how big is the
>> > performance
>> > difference if you had less requests that do more work?
>>
>> You must mean concurrency less than 10?
>>
>> I'm not really certain how concurrency relates to this.  All the tests
>> I ran (Node.js, Twisted, Tornado, Simple) were nonblocking servers
>> with a concurrency of 1.
>
>
> 
> Actually those server/framework do support processing multiple request
> concurrently, when one of the request handler/callback is doing I/O it can
> process another request. (Just like the go backend I tested)
> They just don't do parallelism (by default).
> 
>
>>
>>  Maybe - just maybe - it would be possible to
>> increase throughput by using multiple system threads up to the number
>> of cores available... but then you would lose performance due to
>> synchronization.  Probably significantly.  Optimal hardware
>> utilization is one isolated, single-threaded, nonblocking server per
>> core.
>>
>> I really don't know why backends are slow.  Maybe it has something to
>> do with the request queueing system?  Throughput sucks even when
>> backends are doing noops.  Maybe "increased concurrency" would allow
>> more requests to travel through the queueing system at once... but
>> it's hard to imagine this helping out the actual server process at
>> all.
>
>
> Increasing concurrency could help if you are I/O bound, but it will not help
> if you are truly CPU bound.
>
> For a truly cpu-bound request, you are using as much cpu as the instance
> class limit allows for all backends < B8, and half of the CPU limit for B8.
> So with threadsafe: true, you can only process:
> - 1 cpu bound request at a time on B1 B2 B4
> - 2 cpu bound request at a time on B8
>
> If you are not completely CPU bound and idling between CPU burst then
> increasing concurrency would help, just like if you were bound on I/O
> operations.
>
> Hope that clarify the situation a bit.
>
>>
>>  More timeslicing and synchronization on a cpu- and memory-bound
>> problem will reduce performance, not improve it.
>>
>> 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.
>>
>
>
>
> --
> 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.

-- 
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: Backend performance, compared

[Johan Euphrosine]

On Thu, Aug 9, 2012 at 3:40 PM, Jeff Schnitzer  wrote:

> I think I mentioned this before, but there is no I/O in the problem.
> It just collects data in RAM (thousands of individual submissions) and
> waits for the reaper come get the entire set in one fetch.  This is
> why I do not expect concurrency to help.
>

I was just nitpicking because I thought "with a concurrency of 1" applied
to "Node.js servers" and not "the tests I ran", sorry for the
missunderstanding.


> Jeff
>
> On Thu, Aug 9, 2012 at 3:31 AM, Johan Euphrosine 
> wrote:
> >
> >
> >
> > On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer 
> wrote:
> >>
> >> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla 
> wrote:
> >> > Thanks, Jeff. Is it possible to repeat the test with qps < 10 to rule
> >> > out
> >> > the limit that Johan pointed out? In other words, how big is the
> >> > performance
> >> > difference if you had less requests that do more work?
> >>
> >> You must mean concurrency less than 10?
> >>
> >> I'm not really certain how concurrency relates to this.  All the tests
> >> I ran (Node.js, Twisted, Tornado, Simple) were nonblocking servers
> >> with a concurrency of 1.
> >
> >
> > 
> > Actually those server/framework do support processing multiple request
> > concurrently, when one of the request handler/callback is doing I/O it
> can
> > process another request. (Just like the go backend I tested)
> > They just don't do parallelism (by default).
> > 
> >
> >>
> >>  Maybe - just maybe - it would be possible to
> >> increase throughput by using multiple system threads up to the number
> >> of cores available... but then you would lose performance due to
> >> synchronization.  Probably significantly.  Optimal hardware
> >> utilization is one isolated, single-threaded, nonblocking server per
> >> core.
> >>
> >> I really don't know why backends are slow.  Maybe it has something to
> >> do with the request queueing system?  Throughput sucks even when
> >> backends are doing noops.  Maybe "increased concurrency" would allow
> >> more requests to travel through the queueing system at once... but
> >> it's hard to imagine this helping out the actual server process at
> >> all.
> >
> >
> > Increasing concurrency could help if you are I/O bound, but it will not
> help
> > if you are truly CPU bound.
> >
> > For a truly cpu-bound request, you are using as much cpu as the instance
> > class limit allows for all backends < B8, and half of the CPU limit for
> B8.
> > So with threadsafe: true, you can only process:
> > - 1 cpu bound request at a time on B1 B2 B4
> > - 2 cpu bound request at a time on B8
> >
> > If you are not completely CPU bound and idling between CPU burst then
> > increasing concurrency would help, just like if you were bound on I/O
> > operations.
> >
> > Hope that clarify the situation a bit.
> >
> >>
> >>  More timeslicing and synchronization on a cpu- and memory-bound
> >> problem will reduce performance, not improve it.
> >>
> >> 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.
> >>
> >
> >
> >
> > --
> > 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.
>
> --
> 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.
>
>


-- 
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] How can I block curl requests

[alex]

Kate,

If barryhunter is right and all the IPs are coming from the same ISP 
anyway, you can simply block the whole subnetwork ranges of that ISP (at 
least temporary) using dos.yaml:
https://developers.google.com/appengine/docs/python/config/dos

It'll be pain in the ass updating the file every time you encounter new 
subnets but at least you could probably save some quota 'till you move 
somewhere else or figure something out.

-- alex

On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
>
> Hi Sergey,
>
> Here is a typical example
> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 (i386-redhat-linux-gnu) 
> libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18
> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 153 
> - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0zlib/1.2.3 
> libidn/0.6.14 libssh2/0.18" "
> aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
> instance=00c61b117c2f994812ed63184c9c5544dea738
>
> But the ip address varies. My code forces 302 response. Before I added the 
> code they were throwing errors head method not found. But even though I am 
> doing the 303 I am still getting front end time exceeded and these requests 
> are taking up about 95% of my quota. So to keep the site alive I would have 
> to pay for them, I have lost most of my European and Australian visitors 
> because the site is down every night during those places daylight hours. 
> Obviously I can't continue like this and so will have to move to a provider 
> capable of blocking these requests,
>
>

-- 
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/-/wVEHfRdsXM0J.
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: Backend performance, compared

[Jeff Schnitzer]

I generally am sympathetic to "GAE costs more because it offers more".
 But there's a finite limit to what that "more" is worth.  2X?  3X?

Consider that those 10 B1s are barely keeping up with a load of 2k
users.  A single $11/mo Node instance handles more than 10k users in
my tests.  As we've been talking about this, Richard's user #s are
growing, and now he needs more than 10 B1s.  So to put this in proper
comparison, even _with_ the discount that isn't currently available,
we're comparing cost to support 10k users:

50 B1s = $1,800/mo
2 Node instances (the second for redundancy) = $22/mo

We're talking almost 100X.  Two full orders of magnitude more expensive.

But yes, I would happily offer the score-server service for $360/mo,
let alone $1800!  However, Richard is smart enough to run these on his
own.  My VPS instances have uptimes of 129 days, and that's just
because I did a kernel upgrade.

BTW, my goal in having this conversation is to encourage you guys to
make backends either:  1) a lot cheaper or 2) perform a *lot* better.
Ideally both.

Jeff

On Thu, Aug 9, 2012 at 12:18 AM, Takashi Matsuo  wrote:
> First of all, thank you for the detailed cost comparison and the
> honest feedback. We really appreciate it.
>
> The data itself is not very far from what I observed in my test.
> Certainly, we should try making the backends cheaper. The easiest fix
> will be this issue:
> http://code.google.com/p/googleappengine/issues/detail?id=7411
>
> It will reduce the cost by 5/8(if the discount rate is the same as the
> one for frontend), so it'll be $360/month for 10 B1s.
>
> Besides the cost, we should also improve the performance itself.
>
> You might say 'It's still insane', however, I don't think so, because
> App Engine backends provides other goodies like high availability,
> redundancy, maintenance-free nature from the start.
>
> Please think this way. Would you like to offer a score-server service
> for Richard by yourself at a cost of $360/month? Besides running a
> single node.js server, you also need to run a spare server, need to
> create a monitoring/fail-over mechanism, need to have a support
> channel when in trouble, and sometimes need to diagnose any network
> problem between App Engine and your server.
>
> If the answer is yes, probably it's a good business chance for you ;)
>
> I'm not saying that App Engine is perfect, but i just wanted to point
> out that your comparison lacks(maybe it's intentional) a consideration
> for the important aspects of App Engine.
>
> However, your feedback is still invaluable to us. Thank you as always.
>
> Regards,
>
> -- Takashi
>
>
> On Thu, Aug 9, 2012 at 3:31 PM, Jeff Schnitzer  wrote:
>> On Wed, Aug 8, 2012 at 11:01 PM, Kristopher Giesing
>>  wrote:
>>> Do we know for sure that front ends are any faster?  Their individual
>>> throughput limits might just be masked by having more of them spin up.
>>
>> I expect frontends are about the same.  But frontends can't aggregate
>> scores so they aren't really an issue in this test.  If you want to
>> feel even worse for Richard, he's paying for what seems like an
>> unreasonable number of F1 instances too... but for some reason that
>> seems less frustrating than the totally unnecessary need to add a
>> second equivalent number of backends.
>>
>> 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.
>>
>
>
>
> --
> Takashi Matsuo | Developer Advocate | tmat...@google.com
>
> --
> 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] Boston Google App Engine Developers Group

[J Singh]

Hi everyone,

I hope it is OK to post this message here. I'm one of the organizers of Boston 
Google App Engine Developers  and 
wanted to inform local developers and businesses about the community.

   - Feel free to join the group using the link above.
   - We're always looking for speakers for future meetings. If interested, 
   please *reply to me directly*.


-- 
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/-/8TUa4VFFzo4J.
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] Preventing GAE edge-cache caching

[prem]

Takashi, barryhunter, Emanuele ... Am glad I posted here, thanks for the 
suggestions.

I will have to read up more on cache-control headers to figure out how to 
make the browsers cache the document but still check for freshness with 
origin before expiry. 

-- 
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/-/HIhCteRHa7IJ.
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: Backend performance, compared

[Kristopher Giesing]

The reason I'm currently using them is to avoid insane instancing behavior 
on front ends.  (Which is sad, because I'm basically paying extra to avoid 
a feature.)

I just commented on your SO post, btw, asking clarification on whether your 
rules are only for backends, because I definitely *don't* see that behavior 
for front ends.

- Kris

On Wednesday, August 8, 2012 11:21:48 PM UTC-7, Jeff Schnitzer wrote:
>
> On Wed, Aug 8, 2012 at 10:05 PM, vlad > 
> wrote: 
> > Because I thought that all 3 methods that did not work involved storing 
> data 
> > in Datastore. If you used Backend RAM as storage, well, ok it is an 
> > inventive way to use Backend, I guess. I think Backends are a wrong 
> feature 
> > all together. I just does not with GAE  concept as a scalable, 
> > no-configuration system. But I guess we have ourselves to blame. Some of 
> us 
> > screamed so much about 60 sec time limit in front-ends. And this time 
> Google 
> > decided to "listen" and gave us Backends :) 
>
> Only one of the 3 failed attempts used the datastore; the others were 
> task queue and single-backend. 
>
> I also think that backends are a misfeature, but for different reasons: 
>
>  * As an in-memory index, they are waaay too expensive for any 
> reasonable quantity of RAM. 
>  * As a repository of in-game state (ie this case), they don't provide 
> enough throughput. 
>  * As a way around the 60s timeout for frontends... I'd really just 
> rather have the ability to run frontend requests longer.  And to 
> define groups of frontends of different sizes. 
>
> As Google Compute Engine rolls out, I expect the appeal of backends 
> will diminish considerably.  Which is too bad, because if they were 
> cheaper and faster they would be really incredibly useful. 
>
> Jeff 
>

-- 
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/-/Ln4L5qG42d4J.
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: Backend performance, compared

[Hernan Liendo]

*This is the best thread during this month!

On Racetown we've similar issues. Based on our experience having different 
services such as GAE and Rackspace in the same project (ie scores vs. the 
rest of the game) tend to complex things. 
After a while you will need to share data between both technologies 
incurring in data migration needs. For instance sharing user between 
Rackspace hosted score system and the rest of the game.

We did that on GAE hosted game with metrics logging on Rackspace. 
Maintenance of that solution was painful because Rackspace Linux/Apache 
maintenance, monitoring and also integration between GAE and this service.  
Finally we opted for paying a little more and having everything on GAE side.

On the other hand, I think you could simplify a little your scoring 
solution. What if you hold user’s scores on sharded MemCache entries and 
after a while you get all of them and save the result on the DataStore?*

On Thursday, August 9, 2012 11:04:32 AM UTC-3, Jeff Schnitzer wrote:
>
> I generally am sympathetic to "GAE costs more because it offers more". 
>  But there's a finite limit to what that "more" is worth.  2X?  3X? 
>
> Consider that those 10 B1s are barely keeping up with a load of 2k 
> users.  A single $11/mo Node instance handles more than 10k users in 
> my tests.  As we've been talking about this, Richard's user #s are 
> growing, and now he needs more than 10 B1s.  So to put this in proper 
> comparison, even _with_ the discount that isn't currently available, 
> we're comparing cost to support 10k users: 
>
> 50 B1s = $1,800/mo 
> 2 Node instances (the second for redundancy) = $22/mo 
>
> We're talking almost 100X.  Two full orders of magnitude more expensive. 
>
> But yes, I would happily offer the score-server service for $360/mo, 
> let alone $1800!  However, Richard is smart enough to run these on his 
> own.  My VPS instances have uptimes of 129 days, and that's just 
> because I did a kernel upgrade. 
>
> BTW, my goal in having this conversation is to encourage you guys to 
> make backends either:  1) a lot cheaper or 2) perform a *lot* better. 
> Ideally both. 
>
> Jeff 
>
> On Thu, Aug 9, 2012 at 12:18 AM, Takashi Matsuo 
> > 
> wrote: 
> > First of all, thank you for the detailed cost comparison and the 
> > honest feedback. We really appreciate it. 
> > 
> > The data itself is not very far from what I observed in my test. 
> > Certainly, we should try making the backends cheaper. The easiest fix 
> > will be this issue: 
> > http://code.google.com/p/googleappengine/issues/detail?id=7411 
> > 
> > It will reduce the cost by 5/8(if the discount rate is the same as the 
> > one for frontend), so it'll be $360/month for 10 B1s. 
> > 
> > Besides the cost, we should also improve the performance itself. 
> > 
> > You might say 'It's still insane', however, I don't think so, because 
> > App Engine backends provides other goodies like high availability, 
> > redundancy, maintenance-free nature from the start. 
> > 
> > Please think this way. Would you like to offer a score-server service 
> > for Richard by yourself at a cost of $360/month? Besides running a 
> > single node.js server, you also need to run a spare server, need to 
> > create a monitoring/fail-over mechanism, need to have a support 
> > channel when in trouble, and sometimes need to diagnose any network 
> > problem between App Engine and your server. 
> > 
> > If the answer is yes, probably it's a good business chance for you ;) 
> > 
> > I'm not saying that App Engine is perfect, but i just wanted to point 
> > out that your comparison lacks(maybe it's intentional) a consideration 
> > for the important aspects of App Engine. 
> > 
> > However, your feedback is still invaluable to us. Thank you as always. 
> > 
> > Regards, 
> > 
> > -- Takashi 
> > 
> > 
> > On Thu, Aug 9, 2012 at 3:31 PM, Jeff Schnitzer 
> > > 
> wrote: 
> >> On Wed, Aug 8, 2012 at 11:01 PM, Kristopher Giesing 
> >> > wrote: 
> >>> Do we know for sure that front ends are any faster?  Their individual 
> >>> throughput limits might just be masked by having more of them spin up. 
> >> 
> >> I expect frontends are about the same.  But frontends can't aggregate 
> >> scores so they aren't really an issue in this test.  If you want to 
> >> feel even worse for Richard, he's paying for what seems like an 
> >> unreasonable number of F1 instances too... but for some reason that 
> >> seems less frustrating than the totally unnecessary need to add a 
> >> second equivalent number of backends. 
> >> 
> >> 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-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. 
> >> 
> > 
> > 
> > 
> > -- 
> > Tak

Re: [google-appengine] how can I do a GAE project without .appspot.com

[Shilendra Sharma]

Hi.. Robert

Thanks for suggests Its the very useful because custom domain .  

On Wednesday, 8 August 2012 11:24:02 UTC+5:30, Robert Fischer wrote:
>
> Is it acceptable to have it hosted on both addresses? If not you could 
> always check the url attribute on the request and redirect requests to the 
> non appspot.com name.
>
> I run www.dealscorcher.com (dealscorcher.appspot.com) and www.uripis.com (
> uripaddress.appspot.com) which are set up using the instructions for a 
> custom domain here:  https://developers.google.com/appengine/docs/domain
>
> Hope this helps,
> Robert
>
> On Mon, Aug 6, 2012 at 10:45 PM, Shilendra Sharma 
> 
> > wrote:
>
>>
>> Hi.. All
>>
>> how can I do a gae project without .appspot.com. bcoz till now I am 
>> using this with appspot.com but when I search this by any search engine 
>> like google it not found it need the full url for this application 
>>
>> -- 
>> 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/-/_7Mf1aYzdvsJ.
>> 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/-/gyfnukD7uqIJ.
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] Please whitelist my app for sending mail with OAuth

[Daniel Florey]

Hi,
I am using OpenID / OAuth and I get the "Unauthorized Sender" exception 
when sending out emails on behalf of the user.
Can someone please whitelist my app so that I am able to use the 
MailService with OpenID?
app-id: floreysoftultradox
Thanks!

Daniel

-- 
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/-/xBnH7o9X4KQJ.
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] Customizing App ID, App Title and Auth Options

[zharvey]

Last night I read the online docs for GAE and today I am trying to set up my 
first GAE app. Three questions that are all similarly-related:

(1) I want to purchase my own domain (e.g. my-app.com); but during the app 
creation process I have to specify an app ID of "my-app.appspot.com". How do I 
configure my GAE app so that it is "hosted" from my-app.com and not the appspot 
domain?

(2) I would like to display my own page titles via HTML head/title tags, but 
during the app creation process I have to specify an "App Title". Does this 
mean all pages of my app will be "overridden" with this specified title, and if 
so, how to I override that title with my own ones (for each page)? If not, then 
where is this App Title used/displayed?

(3) I want to authenticate my app's users using my own OWASP-compliannt 
authentication service (so that, say, john@example.com can sign up and 
login to my app with that email address). But during the app creation process I 
have to choose between: (a) making it available to all Google Accounts users, 
(b) making it available to only certain Google Apps Accounts users, or (c) 
making it available via OpenID. I don't want any of these! Like I said, users 
with any email address should be able to register with my app and log in to it, 
without having to use Google accounts or OpenID. Is this possible, and if so 
how?

I have to assume the 3rd question is possible, because there are apps that are 
fully open to the public and that don't require signing in to (no auth).

Thanks in advance!

-- 
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/-/MWPGbB9gAZEJ.
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

I made a cloudflare account but it can't resolve my domain name, 
www.australiansabroad.com as I don't have a dns entry at network 
solutions.com where I register my sites. I have a special entry that google 
resolves. And if I put in my appspot site name cloudflare says it cannot 
accept that.


On Thursday, August 9, 2012 6:38:16 AM UTC-4, Ernesto Oltra wrote:
>
> Have you tried CloudFlare? It's basically the same, a proxy to your app, 
> and you don't have to make/admin it. It has a reputation system, and some 
> others pretty good settings to deal with DOS attacks.
>
> BTW, I'm not affiliated at all with the company, I'm only other web dev.
>
> On Thursday, August 9, 2012 5:12:17 AM UTC+2, Kate wrote:
>>
>> My site has been on GAE for several years but am now experiencing denial 
>> of service attacks. I don't want to pay for them so my site is now down. I 
>> put in a production issue last week and have tried blocking the user agent 
>> (curl). But I can't block by IP as all IPs are different.
>>
>> Apart from moving from GAE what can  I do.
>>
>> Thanks in advance,
>>
>> Kate
>>
>>

-- 
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/-/Ayv0M-GUEmIJ.
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] How can I block curl requests

[Kate]

They are not coming from the same IP. They are mostly in Europe but there 
are no subnets.

There are hundreds of them and google only lets you block 100.

eg

132.65.240.100 
133.15.59.2 
193.136.19.13 
139.165.12.211 
193.166.167.5 
141.219.252.133 
200.17.202.195
195.130.124.1
193.1.201.27 
138.48.3.202 
136.159.220.40 
138.251.214.78 


all these and more within a minute.

They are all different.

Kate



On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
>
> Kate,
>
> If barryhunter is right and all the IPs are coming from the same ISP 
> anyway, you can simply block the whole subnetwork ranges of that ISP (at 
> least temporary) using dos.yaml:
> https://developers.google.com/appengine/docs/python/config/dos
>
> It'll be pain in the ass updating the file every time you encounter new 
> subnets but at least you could probably save some quota 'till you move 
> somewhere else or figure something out.
>
> -- alex
>
> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
>>
>> Hi Sergey,
>>
>> Here is a typical example
>> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 
>> (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
>> libidn/0.6.14 libssh2/0.18
>> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 153 
>> - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0zlib/1.2.3 
>> libidn/0.6.14 libssh2/0.18" "
>> aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
>> instance=00c61b117c2f994812ed63184c9c5544dea738
>>
>> But the ip address varies. My code forces 302 response. Before I added 
>> the code they were throwing errors head method not found. But even though I 
>> am doing the 303 I am still getting front end time exceeded and these 
>> requests are taking up about 95% of my quota. So to keep the site alive I 
>> would have to pay for them, I have lost most of my European and Australian 
>> visitors because the site is down every night during those places daylight 
>> hours. Obviously I can't continue like this and so will have to move to a 
>> provider capable of blocking these requests,
>>
>>

-- 
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/-/g_yrLQPI49cJ.
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: Low hitting site experiencing denial of service attack - site opffline!

[Kate]

My site is in Python.

I am afraid the attackers have won.

It seems nothing can be done and we on GAE have to put up with it. Or pay. 
I will increase my quota while I move my site and cop it sweet as they say 
in Australia. Thanks for everyone who tried to help. 


Kate



On Thursday, August 9, 2012 2:13:01 AM UTC-4, Kristopher Giesing wrote:
>
> There's a short example of a node.js proxy server here:
>
> http://www.catonmat.net/http-proxy-in-nodejs/
>
> It might not be as hard as you imagine to get this working.  I'd hate to 
> see the attackers win :(
>
> - Kris
>
> On Wednesday, August 8, 2012 10:06:45 PM UTC-7, Kate wrote:
>>
>> I don't know how to write the node.js. I am surprised that google cannot 
>> help me here. I do appreciate your help but I just can't do this without 
>> spending hours of study. To answer your other question, the blocking 
>> attempt didn't solve the problem. The curl requests come about 3 times per 
>>  second. I have been working on trying to stop them for over a week now. I 
>> suppose I can just change my domain name or move to another hosting service 
>> but it seems a pity.
>>
>> I have had this site since 1996 with never a problem. 
>>
>

-- 
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/-/5y6f_3Sj3ooJ.
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] How can I block curl requests

[Joshua Smith]

If you put those into an IP lookup utility, you'll find that they are actually 
all "planetlab" related.

I believe that what is happening is you are being DOS'd by a botnet created by 
these guys: http://www.planet-lab.org

To report a suspected violation of this policy, contact PlanetLab Support 
(supp...@planet-lab.org).

If that doesn't stop it, sue them. Call the FBI. Contact everyone on the 
steering committe: http://www.planet-lab.org/consortium

On Aug 9, 2012, at 12:13 PM, Kate  wrote:

> They are not coming from the same IP. They are mostly in Europe but there are 
> no subnets.
> 
> There are hundreds of them and google only lets you block 100.
> 
> eg
> 132.65.240.100 
> 133.15.59.2 
> 193.136.19.13 
> 139.165.12.211 
> 193.166.167.5 
> 141.219.252.133 
> 200.17.202.195
> 195.130.124.1
> 193.1.201.27 
> 138.48.3.202 
> 136.159.220.40 
> 138.251.214.78 
> 
> 
> all these and more within a minute.
> 
> They are all different.
> 
> Kate
> 
> 
> 
> On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
> Kate,
> 
> If barryhunter is right and all the IPs are coming from the same ISP anyway, 
> you can simply block the whole subnetwork ranges of that ISP (at least 
> temporary) using dos.yaml:
> https://developers.google.com/appengine/docs/python/config/dos
> 
> It'll be pain in the ass updating the file every time you encounter new 
> subnets but at least you could probably save some quota 'till you move 
> somewhere else or figure something out.
> 
> -- alex
> 
> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
> Hi Sergey,
> Here is a typical example
> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 (i386-redhat-linux-gnu) 
> libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18
> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 153 - 
> "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
> libidn/0.6.14 libssh2/0.18" "aussieclouds.appspot.com" ms=31 cpu_ms=0 
> api_cpu_ms=0 cpm_usd=0.49 instance=00c61b117c2f994812ed63184c9c5544dea738
> 
> But the ip address varies. My code forces 302 response. Before I added the 
> code they were throwing errors head method not found. But even though I am 
> doing the 303 I am still getting front end time exceeded and these requests 
> are taking up about 95% of my quota. So to keep the site alive I would have 
> to pay for them, I have lost most of my European and Australian visitors 
> because the site is down every night during those places daylight hours. 
> Obviously I can't continue like this and so will have to move to a provider 
> capable of blocking these requests,
> 
> 
> 
> -- 
> 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/-/g_yrLQPI49cJ.
> 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: Customizing App ID, App Title and Auth Options

[Michael Hermus]

1) You need to set up your domain with Google Apps and then you can 
configure your GAE app to use the custom domain: 
https://developers.google.com/appengine/docs/domain

2) The App title is for displaying in the Google Authentication process to 
users (if you use it). It has nothing to do with your HTML pages.

3) You are free to implement whatever custom authentication you like; those 
options are if you want to use Google's built in User Authentication 
service.

On Thursday, August 9, 2012 11:18:02 AM UTC-4, zharvey wrote:
>
> Last night I read the online docs for GAE and today I am trying to set up 
> my first GAE app. Three questions that are all similarly-related:
>
> (1) I want to purchase my own domain (e.g. my-app.com); but during the 
> app creation process I have to specify an app ID of "my-app.appspot.com". 
> How do I configure my GAE app so that it is "hosted" from my-app.com and 
> not the appspot domain?
>
> (2) I would like to display my own page titles via HTML head/title tags, 
> but during the app creation process I have to specify an "App Title". Does 
> this mean all pages of my app will be "overridden" with this specified 
> title, and if so, how to I override that title with my own ones (for each 
> page)? If not, then where is this App Title used/displayed?
>
> (3) I want to authenticate my app's users using my own OWASP-compliannt 
> authentication service (so that, say, john...@example.com can 
> sign up and login to my app with that email address). But during the 
> app creation process I have to choose between: (a) making it available to 
> all Google Accounts users, (b) making it available to only certain Google 
> Apps Accounts users, or (c) making it available via OpenID. I don't want 
> any of these! Like I said, users with any email address should be able to 
> register with my app and log in to it, without having to use Google 
> accounts or OpenID. Is this possible, and if so how?
>
> I have to assume the 3rd question is possible, because there are apps that 
> are fully open to the public and that don't require signing in to (no auth).
>
> Thanks in advance!
>
>

-- 
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/-/vJ7m6LO7yakJ.
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: Customizing App ID, App Title and Auth Options

[zharvey]

Thanks Michael!

Just one quick followup on the 3rd item: if I want to use my own 
authorization services, which option do I select on the initial app 
creation screen?  It doesn't provide an option like "None of the above", it 
forces me to pick one.  Or does it not matter? Thanks again!

On Thursday, August 9, 2012 1:04:23 PM UTC-4, Michael Hermus wrote:
>
> 1) You need to set up your domain with Google Apps and then you can 
> configure your GAE app to use the custom domain: 
> https://developers.google.com/appengine/docs/domain
>
> 2) The App title is for displaying in the Google Authentication process to 
> users (if you use it). It has nothing to do with your HTML pages.
>
> 3) You are free to implement whatever custom authentication you like; 
> those options are if you want to use Google's built in User Authentication 
> service.
>
> On Thursday, August 9, 2012 11:18:02 AM UTC-4, zharvey wrote:
>>
>> Last night I read the online docs for GAE and today I am trying to set up 
>> my first GAE app. Three questions that are all similarly-related:
>>
>> (1) I want to purchase my own domain (e.g. my-app.com); but during the 
>> app creation process I have to specify an app ID of "my-app.appspot.com". 
>> How do I configure my GAE app so that it is "hosted" from my-app.com and 
>> not the appspot domain?
>>
>> (2) I would like to display my own page titles via HTML head/title tags, 
>> but during the app creation process I have to specify an "App Title". Does 
>> this mean all pages of my app will be "overridden" with this specified 
>> title, and if so, how to I override that title with my own ones (for each 
>> page)? If not, then where is this App Title used/displayed?
>>
>> (3) I want to authenticate my app's users using my own OWASP-compliannt 
>> authentication service (so that, say, john...@example.com can sign up 
>> and login to my app with that email address). But during the app creation 
>> process I have to choose between: (a) making it available to all Google 
>> Accounts users, (b) making it available to only certain Google Apps 
>> Accounts users, or (c) making it available via OpenID. I don't want any of 
>> these! Like I said, users with any email address should be able to register 
>> with my app and log in to it, without having to use Google accounts or 
>> OpenID. Is this possible, and if so how?
>>
>> I have to assume the 3rd question is possible, because there are apps 
>> that are fully open to the public and that don't require signing in to (no 
>> auth).
>>
>> Thanks in advance!
>>
>>

-- 
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/-/yZXgBdk00zQJ.
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: Customizing App ID, App Title and Auth Options

[Michael Hermus]

AFAIK, it doesn't really matter if you are not going to utilize Google's 
User API. 

Also, you are able to use your own custom authentication AND Google's 
service if you want to; it makes your implementation a bit more complex, 
but that is actually what I do.


On Thursday, August 9, 2012 1:09:10 PM UTC-4, zharvey wrote:
>
> Thanks Michael!
>
> Just one quick followup on the 3rd item: if I want to use my own 
> authorization services, which option do I select on the initial app 
> creation screen?  It doesn't provide an option like "None of the above", it 
> forces me to pick one.  Or does it not matter? Thanks again!
>
> On Thursday, August 9, 2012 1:04:23 PM UTC-4, Michael Hermus wrote:
>>
>> 1) You need to set up your domain with Google Apps and then you can 
>> configure your GAE app to use the custom domain: 
>> https://developers.google.com/appengine/docs/domain
>>
>> 2) The App title is for displaying in the Google Authentication process 
>> to users (if you use it). It has nothing to do with your HTML pages.
>>
>> 3) You are free to implement whatever custom authentication you like; 
>> those options are if you want to use Google's built in User Authentication 
>> service.
>>
>> On Thursday, August 9, 2012 11:18:02 AM UTC-4, zharvey wrote:
>>>
>>> Last night I read the online docs for GAE and today I am trying to set 
>>> up my first GAE app. Three questions that are all similarly-related:
>>>
>>> (1) I want to purchase my own domain (e.g. my-app.com); but during the 
>>> app creation process I have to specify an app ID of "my-app.appspot.com". 
>>> How do I configure my GAE app so that it is "hosted" from my-app.comand not 
>>> the appspot domain?
>>>
>>> (2) I would like to display my own page titles via HTML head/title tags, 
>>> but during the app creation process I have to specify an "App Title". Does 
>>> this mean all pages of my app will be "overridden" with this specified 
>>> title, and if so, how to I override that title with my own ones (for each 
>>> page)? If not, then where is this App Title used/displayed?
>>>
>>> (3) I want to authenticate my app's users using my own OWASP-compliannt 
>>> authentication service (so that, say, john...@example.com can sign up 
>>> and login to my app with that email address). But during the app creation 
>>> process I have to choose between: (a) making it available to all Google 
>>> Accounts users, (b) making it available to only certain Google Apps 
>>> Accounts users, or (c) making it available via OpenID. I don't want any of 
>>> these! Like I said, users with any email address should be able to register 
>>> with my app and log in to it, without having to use Google accounts or 
>>> OpenID. Is this possible, and if so how?
>>>
>>> I have to assume the 3rd question is possible, because there are apps 
>>> that are fully open to the public and that don't require signing in to (no 
>>> auth).
>>>
>>> Thanks in advance!
>>>
>>>

-- 
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/-/hCFbGhZsKTgJ.
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] How can I block curl requests

[Michael Hermus]

Planet Lab seems to be a platform that supports a large number of third 
party projects. My guess would be that it isn't actually the people at 
Planet Lab themselves, but rather some user that created a bot which is 
running amok (either deliberately or by mistake).

Regardless, Joshua is right: you should contact them ASAP and let them know 
what is happening.

On Thursday, August 9, 2012 1:03:49 PM UTC-4, Joshua Smith wrote:
>
> If you put those into an IP lookup utility, you'll find that they are 
> actually all "planetlab" related.
>
> I believe that what is happening is you are being DOS'd by a botnet 
> created by these guys: http://www.planet-lab.org
>
> To report a suspected violation of this policy, contact PlanetLab Support (
> sup...@planet-lab.org ).
>
> If that doesn't stop it, sue them. Call the FBI. Contact everyone on the 
> steering committe: http://www.planet-lab.org/consortium
>
> On Aug 9, 2012, at 12:13 PM, Kate > wrote:
>
> They are not coming from the same IP. They are mostly in Europe but there 
> are no subnets.
>
> There are hundreds of them and google only lets you block 100.
>
> eg
>
> 132.65.240.100 
> 133.15.59.2 
> 193.136.19.13 
> 139.165.12.211 
> 193.166.167.5 
> 141.219.252.133 
> 200.17.202.195
> 195.130.124.1
> 193.1.201.27 
> 138.48.3.202 
> 136.159.220.40 
> 138.251.214.78 
>
>
> all these and more within a minute.
>
> They are all different.
>
> Kate
>
>
>
> On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
>>
>> Kate,
>>
>> If barryhunter is right and all the IPs are coming from the same ISP 
>> anyway, you can simply block the whole subnetwork ranges of that ISP (at 
>> least temporary) using dos.yaml:
>> https://developers.google.com/appengine/docs/python/config/dos
>>
>> It'll be pain in the ass updating the file every time you encounter new 
>> subnets but at least you could probably save some quota 'till you move 
>> somewhere else or figure something out.
>>
>> -- alex
>>
>> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
>>>
>>> Hi Sergey,
>>>
>>> Here is a typical example
>>> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 
>>> (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
>>> libidn/0.6.14 libssh2/0.18
>>> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 
>>> 153 - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 
>>> NSS/3.12.2.0zlib/1.2.3 libidn/0.6.14 libssh2/0.18" "
>>> aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
>>> instance=00c61b117c2f994812ed63184c9c5544dea738
>>>
>>> But the ip address varies. My code forces 302 response. Before I added 
>>> the code they were throwing errors head method not found. But even though I 
>>> am doing the 303 I am still getting front end time exceeded and these 
>>> requests are taking up about 95% of my quota. So to keep the site alive I 
>>> would have to pay for them, I have lost most of my European and Australian 
>>> visitors because the site is down every night during those places daylight 
>>> hours. Obviously I can't continue like this and so will have to move to a 
>>> provider capable of blocking these requests,
>>>
>>>
> -- 
> 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/-/g_yrLQPI49cJ.
> 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/-/fSpLK28SugUJ.
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] How can I block curl requests

[alex]

well, while you're notifying planetlab and whatnot you could create and 
upload a dos.yaml for the time being with a content similar to this:

blacklist:
- subnet: 132.65.0.0/16
- subnet: 133.0.0.0/8
  description: somewhere in china
- subnet: 136.159.0.0/16
- subnet: 138.250.0.0/15
- subnet: 138.48.0.0/16
- subnet: 139.165.0.0/16
- subnet: 141.219.252.0/24
- subnet: 193.1.0.0/16
  description: planetlab
- subnet: 193.136.16.0/24
- subnet: 193.166.167.0/24
- subnet: 195.130.124.0/22
- subnet: 200.17.192.0/19


- put that file in your app root dir and do something like this from a 
terminal:

"appcfg.py update_dos ."


On Thursday, August 9, 2012 6:13:14 PM UTC+2, Kate wrote:
>
> They are not coming from the same IP. They are mostly in Europe but there 
> are no subnets.
>
> There are hundreds of them and google only lets you block 100.
>
> eg
>
> 132.65.240.100 
> 133.15.59.2 
> 193.136.19.13 
> 139.165.12.211 
> 193.166.167.5 
> 141.219.252.133 
> 200.17.202.195
> 195.130.124.1
> 193.1.201.27 
> 138.48.3.202 
> 136.159.220.40 
> 138.251.214.78 
>
>
> all these and more within a minute.
>
> They are all different.
>
> Kate
>
>
>
> On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
>>
>> Kate,
>>
>> If barryhunter is right and all the IPs are coming from the same ISP 
>> anyway, you can simply block the whole subnetwork ranges of that ISP (at 
>> least temporary) using dos.yaml:
>> https://developers.google.com/appengine/docs/python/config/dos
>>
>> It'll be pain in the ass updating the file every time you encounter new 
>> subnets but at least you could probably save some quota 'till you move 
>> somewhere else or figure something out.
>>
>> -- alex
>>
>> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
>>>
>>> Hi Sergey,
>>>
>>> Here is a typical example
>>> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 
>>> (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
>>> libidn/0.6.14 libssh2/0.18
>>> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 
>>> 153 - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 
>>> NSS/3.12.2.0zlib/1.2.3 libidn/0.6.14 libssh2/0.18" "
>>> aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
>>> instance=00c61b117c2f994812ed63184c9c5544dea738
>>>
>>> But the ip address varies. My code forces 302 response. Before I added 
>>> the code they were throwing errors head method not found. But even though I 
>>> am doing the 303 I am still getting front end time exceeded and these 
>>> requests are taking up about 95% of my quota. So to keep the site alive I 
>>> would have to pay for them, I have lost most of my European and Australian 
>>> visitors because the site is down every night during those places daylight 
>>> hours. Obviously I can't continue like this and so will have to move to a 
>>> provider capable of blocking these requests,
>>>
>>>

-- 
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/-/vD82ECZ5npEJ.
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: Anybody interested in a Datastore Manager for GAE?

[hugues2]

I would be interested. One feature I would love is next to query being 
update with SQL Like query "Update kind xxx set y=z where conditions ..."

Thanks,

Hugues


Le mercredi 8 août 2012 23:41:52 UTC+2, Backpack a écrit :
>
> Something like phpMyAdmin for MySQL but adapted to the datastore. 
> If so, answer these questions: 
>
> - What datastore: db, ndb or SQL? 
> - How much would you pay for that? 
> - Pay once use forever with yearly versions?  ~$100/ver 
> - or pay monthly with free updates? ~$10/mo 
> - web based or desktop app? 
>
> I am thinking on doing one with the latest HTML,CSS,JS stuff (sorry 
> IE) and just wanted to see if there was any interest in a tool like 
> that. The data viewer and data admin stuff offered by gae are limited 
> in functionality. 
>
> Thanks for your time in answering the questions. 
>

-- 
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/-/YCReClSA1ycJ.
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] How can I block curl requests

[Kate]

Thanks,

I emailed support. Tried to look up their steering committee but their 
database is dowwn. Will let you all know what I hear back!


On Thursday, August 9, 2012 1:03:49 PM UTC-4, Joshua Smith wrote:
>
> If you put those into an IP lookup utility, you'll find that they are 
> actually all "planetlab" related.
>
> I believe that what is happening is you are being DOS'd by a botnet 
> created by these guys: http://www.planet-lab.org
>
> To report a suspected violation of this policy, contact PlanetLab Support (
> sup...@planet-lab.org ).
>
> If that doesn't stop it, sue them. Call the FBI. Contact everyone on the 
> steering committe: http://www.planet-lab.org/consortium
>
> On Aug 9, 2012, at 12:13 PM, Kate > wrote:
>
> They are not coming from the same IP. They are mostly in Europe but there 
> are no subnets.
>
> There are hundreds of them and google only lets you block 100.
>
> eg
>
> 132.65.240.100 
> 133.15.59.2 
> 193.136.19.13 
> 139.165.12.211 
> 193.166.167.5 
> 141.219.252.133 
> 200.17.202.195
> 195.130.124.1
> 193.1.201.27 
> 138.48.3.202 
> 136.159.220.40 
> 138.251.214.78 
>
>
> all these and more within a minute.
>
> They are all different.
>
> Kate
>
>
>
> On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
>>
>> Kate,
>>
>> If barryhunter is right and all the IPs are coming from the same ISP 
>> anyway, you can simply block the whole subnetwork ranges of that ISP (at 
>> least temporary) using dos.yaml:
>> https://developers.google.com/appengine/docs/python/config/dos
>>
>> It'll be pain in the ass updating the file every time you encounter new 
>> subnets but at least you could probably save some quota 'till you move 
>> somewhere else or figure something out.
>>
>> -- alex
>>
>> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:
>>>
>>> Hi Sergey,
>>>
>>> Here is a typical example
>>> 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 
>>> (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
>>> libidn/0.6.14 libssh2/0.18
>>> 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 
>>> 153 - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 
>>> NSS/3.12.2.0zlib/1.2.3 libidn/0.6.14 libssh2/0.18" "
>>> aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
>>> instance=00c61b117c2f994812ed63184c9c5544dea738
>>>
>>> But the ip address varies. My code forces 302 response. Before I added 
>>> the code they were throwing errors head method not found. But even though I 
>>> am doing the 303 I am still getting front end time exceeded and these 
>>> requests are taking up about 95% of my quota. So to keep the site alive I 
>>> would have to pay for them, I have lost most of my European and Australian 
>>> visitors because the site is down every night during those places daylight 
>>> hours. Obviously I can't continue like this and so will have to move to a 
>>> provider capable of blocking these requests,
>>>
>>>
> -- 
> 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/-/g_yrLQPI49cJ.
> 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/-/FIuRs3_jpfEJ.
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] Suddenly cannot access some spreadsheets in Google Doc

[smclrnd]

One Google Doc has a few spreadsheets in it. Used API to access 
spreadsheets in the application hosted on GAE. Previously everything worked 
fine. This morning, suddenly some spreadsheets in this document cannot be 
found through the same API. However, some other spreadsheets were still 
accessible. No change to the application and the doc recently. Is there any 
problem with GAE? Any reasonable explanation?

-- 
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/-/7sVasCDjKyMJ.
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] How can I block curl requests

[Kate]

I did that but don't think it will catch them all.

I had a list of 100 individual ones, see below. Can you recognize subnets 
in them?
blacklist:
- subnet: 82.179.176.44
- subnet: 83.230.127.124
- subnet: 88.2.234.60
- subnet: 128.10.19.53
- subnet: 128.84.154.45
- subnet: 128.42.142.44
- subnet: 128.36.233.154
- subnet: 128.111.52.59
- subnet: 128.114.63.64
- subnet: 128.138.207.45
- subnet: 128.227.150.12
- subnet: 128.208.4.198
- subnet: 128.151.65.101
- subnet: 128.223.8.112
- subnet: 128.232.103.201
- subnet: 129.10.120.194
- subnet: 129.15.78.30
- subnet: 129.74.74.20
- subnet: 129.82.12.188
- subnet: 129.93.229.139
- subnet: 129.97.74.14
- subnet: 129.108.202.11
- subnet: 129.130.252.140
- subnet: 129.237.161.194
- subnet: 130.37.193.143
- subnet: 130.83.166.243
- subnet: 130.104.72.213
- subnet: 130.216.1.22
- subnet: 130.253.21.123
- subnet: 130.195.4.68
- subnet: 130.237.50.125
- subnet: 131.179.150.72
- subnet: 131.188.44.102
- subnet: 132.65.240.100
- subnet: 132.72.23.10
- subnet: 132.170.3.32
- subnet: 132.181.10.56
- subnet: 133.1.74.163
- subnet: 133.15.59.2
- subnet: 133.68.253.242
- subnet: 134.151.255.181
- subnet: 138.4.0.120
- subnet: 138.251.214.78
- subnet: 136.159.220.40
- subnet: 138.48.3.202
- subnet: 139.78.141.245
- subnet: 139.165.12.211
- subnet: 140.109.17.181
- subnet: 140.112.107.82
- subnet: 140.123.230.248
- subnet: 141.11.0.162
- subnet: 141.20.103.211
- subnet: 141.219.252.133
- subnet: 142.103.2.2
- subnet: 143.89.49.73
- subnet: 143.225.229.238
- subnet: 155.245.47.225
- subnet: 155.246.12.163
- subnet: 156.56.250.226
- subnet: 156.62.231.244
- subnet: 157.92.44.101
- subnet: 160.80.221.39
- subnet: 161.106.240.19
- subnet: 169.226.40.2
- subnet:  169.229.50.15
- subnet: 165.91.55.8
- subnet: 165.230.49.115
- subnet: 192.1.249.138
- subnet: 192.12.33.102
- subnet: 192.16.125.11
- subnet: 192.38.109.144
- subnet: 192.41.135.219
- subnet: 192.42.43.23
- subnet: 192.107.171.145
- subnet: 193.1.201.27
- subnet: 193.138.2.13
- subnet: 193.196.39.9
- subnet: 193.167.187.185
- subnet: 193.136.19.13
- subnet: 193.166.167.5
- subnet: 193.205.215.74
- subnet: 193.226.19.31
- subnet: 194.29.178.13
- subnet: 194.167.254.19
- subnet: 194.254.215.12
- subnet: 195.130.124.1
- subnet: 198.82.160.221
- subnet: 200.0.206.137
- subnet: 200.0.206.168
- subnet: 200.17.202.195
- subnet: 200.129.132.19
- subnet: 202.23.159.52
- subnet: 202.125.215.12
- subnet: 202.237.248.222
- subnet: 202.249.37.67
- subnet: 203.110.240.190
- subnet: 203.178.133.2
- subnet: 212.51.218.235
- subnet: 213.73.40.106
- subnet: 213.131.1.101

Thanks
Kate


On Thursday, August 9, 2012 2:37:48 PM UTC-4, alex wrote:
>
> well, while you're notifying planetlab and whatnot you could create and 
> upload a dos.yaml for the time being with a content similar to this:
>
> blacklist:
> - subnet: 132.65.0.0/16
> - subnet: 133.0.0.0/8
>   description: somewhere in china
> - subnet: 136.159.0.0/16
> - subnet: 138.250.0.0/15
> - subnet: 138.48.0.0/16
> - subnet: 139.165.0.0/16
> - subnet: 141.219.252.0/24
> - subnet: 193.1.0.0/16
>   description: planetlab
> - subnet: 193.136.16.0/24
> - subnet: 193.166.167.0/24
> - subnet: 195.130.124.0/22
> - subnet: 200.17.192.0/19
>
>
> - put that file in your app root dir and do something like this from a 
> terminal:
>
> "appcfg.py update_dos ."
>
>
> On Thursday, August 9, 2012 6:13:14 PM UTC+2, Kate wrote:
>>
>> They are not coming from the same IP. They are mostly in Europe but there 
>> are no subnets.
>>
>> There are hundreds of them and google only lets you block 100.
>>
>> eg
>>
>> 132.65.240.100 
>> 133.15.59.2 
>> 193.136.19.13 
>> 139.165.12.211 
>> 193.166.167.5 
>> 141.219.252.133 
>> 200.17.202.195
>> 195.130.124.1
>> 193.1.201.27 
>> 138.48.3.202 
>> 136.159.220.40 
>> 138.251.214.78 
>>
>>
>> all these and more within a minute.
>>
>> They are all different.
>>
>> Kate
>>
>>
>>
>> On Thursday, August 9, 2012 9:55:29 AM UTC-4, alex wrote:
>>>
>>> Kate,
>>>
>>> If barryhunter is right and all the IPs are coming from the same ISP 
>>> anyway, you can simply block the whole subnetwork ranges of that ISP (at 
>>> least temporary) using dos.yaml:
>>> https://developers.google.com/appengine/docs/python/config/dos
>>>
>>> It'll be pain in the ass updating the file every time you encounter new 
>>> subnets but at least you could probably save some quota 'till you move 
>>> somewhere else or figure something out.
>>>
>>> -- alex
>>>
>>> On Thursday, August 9, 2012 1:59:57 PM UTC+2, Kate wrote:

 Hi Sergey,

 Here is a typical example
 2012-08-09 06:51:16.597 / 302 30ms 0kb curl/7.18.2 
 (i386-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 
 libidn/0.6.14 libssh2/0.18
 202.125.215.12 - - [09/Aug/2012:04:51:16 -0700] "HEAD / HTTP/1.1" 302 
 153 - "curl/7.18.2 (i386-redhat-linux-gnu) libcurl/7.18.2 
 NSS/3.12.2.0zlib/1.2.3 libidn/0.6.14 libssh2/0.18" "
 aussieclouds.appspot.com" ms=31 cpu_ms=0 api_cpu_ms=0 cpm_usd=0.49 
 in

Re: [google-appengine] How can I block curl requests

[alex]

A lot of those IPs are assigned to universities, like almost literally all 
of them. More than 50% are US universities. This really looks like a big 
distributed bot network to me.

Anyway, here you go (some IPs are from the same net block so there are less 
than 100 entries):


- subnet: 82.179.176.0/20
- subnet: 83.230.96.0/19
- subnet: 88.2.0.0/16
- subnet: 128.10.0.0/16
- subnet: 128.84.0.0/16
- subnet: 128.42.0.0/16
- subnet: 128.36.0.0/16
- subnet: 128.111.0.0/16
- subnet: 128.114.0.0/16
- subnet: 128.138.0.0/16
- subnet: 128.227.0.0/16
- subnet: 128.208.0.0/16
- subnet: 128.151.0.0/16
- subnet: 128.223.0.0/16
- subnet: 128.232.0.0/16
- subnet: 129.10.0.0/16
- subnet: 129.15.0.0/16
- subnet: 129.74.0.0/16
- subnet: 129.82.0.0/16
- subnet: 129.93.0.0/16
- subnet: 129.97.0.0/16
- subnet: 129.108.0.0/16
- subnet: 129.130.0.0/16
- subnet: 129.237.0.0/16
- subnet: 130.37.0.0/16
- subnet: 130.83.0.0/16
- subnet: 130.104.0.0/16
- subnet: 130.216.0.0/16
- subnet: 130.253.0.0/16
- subnet: 130.195.4.0/24
- subnet: 130.237.0.0/18
- subnet: 131.179.0.0/16
- subnet: 131.188.0.0/16
- subnet: 132.64.0.0/13
- subnet: 132.72.0.0/14
- subnet: 134.151.0.0/16
- subnet: 138.4.0.0/16
- subnet: 138.250.0.0/15
- subnet: 138.48.0.0/16
- subnet: 139.165.0.0/16
- subnet: 140.109.0.0/16
- subnet: 143.225.0.0/16
- subnet: 155.245.0.0/16
- subnet: 160.80.0.0/16
- subnet: 161.106.0.0/16
- subnet: 192.16.124.0/22
- subnet: 192.38.0.0/17
- subnet: 192.41.132.0/22
- subnet: 192.42.42.0/23
- subnet: 193.1.0.0/16
- subnet: 193.138.2.0/24
- subnet: 193.196.0.0/15
- subnet: 193.166.0.0/15
- subnet: 193.136.0.0/15
- subnet: 193.166.0.0/15
- subnet: 193.204.0.0/15
- subnet: 193.226.0.0/19
- subnet: 194.29.176.0/22
- subnet: 194.167.0.0/16
- subnet: 194.254.0.0/16
- subnet: 195.130.124.0/22
- subnet: 203.110.240.0/24
- subnet: 212.51.208.0/20
- subnet: 213.73.32.0/19
- subnet: 213.131.0.0/19
- subnet: 136.159.0.0/16
- subnet: 132.170.0.0/16
- subnet: 132.181.0.0/16
- subnet: 133.0.0.0/8
- subnet: 203.0.0.0/8
- subnet: 198.82.0.0/16
- subnet: 200.0.0.0/8
- subnet: 192.107.171.0/24
- subnet: 140.112.0.0/12
- subnet: 140.123.0.0/16
- subnet: 142.103.0.0/16
- subnet: 143.89.0.0/16
- subnet: 139.78.0.0/16
- subnet: 155.246.0.0/16
- subnet: 156.56.0.0/16
- subnet: 156.62.0.0/16
- subnet: 157.92.0.0/16
- subnet: 169.226.0.0/16
- subnet: 165.91.0.0/16
- subnet: 165.230.0.0/16
- subnet: 192.1.0.0/16
- subnet: 192.12.33.0/24
- subnet: 169.229.0.0/16
- subnet: 141.219.0.0/16
# these belong to a too big block
- subnet: 141.11.0.162
- subnet: 141.20.103.211



On Thursday, August 9, 2012 10:21:03 PM UTC+2, Kate wrote:
>
>
> I did that but don't think it will catch them all.
>
> I had a list of 100 individual ones, see below. Can you recognize subnets 
> in them?
> blacklist:
> - subnet: 82.179.176.44
> - subnet: 83.230.127.124
> - subnet: 88.2.234.60
> - subnet: 128.10.19.53
> - subnet: 128.84.154.45
> - subnet: 128.42.142.44
> - subnet: 128.36.233.154
> - subnet: 128.111.52.59
> - subnet: 128.114.63.64
> - subnet: 128.138.207.45
> - subnet: 128.227.150.12
> - subnet: 128.208.4.198
> - subnet: 128.151.65.101
> - subnet: 128.223.8.112
> - subnet: 128.232.103.201
> - subnet: 129.10.120.194
> - subnet: 129.15.78.30
> - subnet: 129.74.74.20
> - subnet: 129.82.12.188
> - subnet: 129.93.229.139
> - subnet: 129.97.74.14
> - subnet: 129.108.202.11
> - subnet: 129.130.252.140
> - subnet: 129.237.161.194
> - subnet: 130.37.193.143
> - subnet: 130.83.166.243
> - subnet: 130.104.72.213
> - subnet: 130.216.1.22
> - subnet: 130.253.21.123
> - subnet: 130.195.4.68
> - subnet: 130.237.50.125
> - subnet: 131.179.150.72
> - subnet: 131.188.44.102
> - subnet: 132.65.240.100
> - subnet: 132.72.23.10
> - subnet: 132.170.3.32
> - subnet: 132.181.10.56
> - subnet: 133.1.74.163
> - subnet: 133.15.59.2
> - subnet: 133.68.253.242
> - subnet: 134.151.255.181
> - subnet: 138.4.0.120
> - subnet: 138.251.214.78
> - subnet: 136.159.220.40
> - subnet: 138.48.3.202
> - subnet: 139.78.141.245
> - subnet: 139.165.12.211
> - subnet: 140.109.17.181
> - subnet: 140.112.107.82
> - subnet: 140.123.230.248
> - subnet: 141.11.0.162
> - subnet: 141.20.103.211
> - subnet: 141.219.252.133
> - subnet: 142.103.2.2
> - subnet: 143.89.49.73
> - subnet: 143.225.229.238
> - subnet: 155.245.47.225
> - subnet: 155.246.12.163
> - subnet: 156.56.250.226
> - subnet: 156.62.231.244
> - subnet: 157.92.44.101
> - subnet: 160.80.221.39
> - subnet: 161.106.240.19
> - subnet: 169.226.40.2
> - subnet:  169.229.50.15
> - subnet: 165.91.55.8
> - subnet: 165.230.49.115
> - subnet: 192.1.249.138
> - subnet: 192.12.33.102
> - subnet: 192.16.125.11
> - subnet: 192.38.109.144
> - subnet: 192.41.135.219
> - subnet: 192.42.43.23
> - subnet: 192.107.171.145
> - subnet: 193.1.201.27
> - subnet: 193.138.2.13
> - subnet: 193.196.39.9
> - subnet: 193.167.187.185
> - subnet: 193.136.19.13
> - subnet: 193.166.167.5
> - subnet: 193.205.215.74
> - subnet: 193.226.19.31
> - subnet: 194.29.178.13
> - subnet: 194.167.254.19
> - subnet:

Re: [google-appengine] How can I block curl requests

[alex]

Actually, scratch last three lines (starting from # these belong to...) and 
replace with

- subnet: 141.0.0.0/8


On Thursday, August 9, 2012 11:32:03 PM UTC+2, alex wrote:
>
> A lot of those IPs are assigned to universities, like almost literally all 
> of them. More than 50% are US universities. This really looks like a big 
> distributed bot network to me.
>
> Anyway, here you go (some IPs are from the same net block so there are 
> less than 100 entries):
>
>
> - subnet: 82.179.176.0/20
> - subnet: 83.230.96.0/19
> - subnet: 88.2.0.0/16
> - subnet: 128.10.0.0/16
> - subnet: 128.84.0.0/16
> - subnet: 128.42.0.0/16
> - subnet: 128.36.0.0/16
> - subnet: 128.111.0.0/16
> - subnet: 128.114.0.0/16
> - subnet: 128.138.0.0/16
> - subnet: 128.227.0.0/16
> - subnet: 128.208.0.0/16
> - subnet: 128.151.0.0/16
> - subnet: 128.223.0.0/16
> - subnet: 128.232.0.0/16
> - subnet: 129.10.0.0/16
> - subnet: 129.15.0.0/16
> - subnet: 129.74.0.0/16
> - subnet: 129.82.0.0/16
> - subnet: 129.93.0.0/16
> - subnet: 129.97.0.0/16
> - subnet: 129.108.0.0/16
> - subnet: 129.130.0.0/16
> - subnet: 129.237.0.0/16
> - subnet: 130.37.0.0/16
> - subnet: 130.83.0.0/16
> - subnet: 130.104.0.0/16
> - subnet: 130.216.0.0/16
> - subnet: 130.253.0.0/16
> - subnet: 130.195.4.0/24
> - subnet: 130.237.0.0/18
> - subnet: 131.179.0.0/16
> - subnet: 131.188.0.0/16
> - subnet: 132.64.0.0/13
> - subnet: 132.72.0.0/14
> - subnet: 134.151.0.0/16
> - subnet: 138.4.0.0/16
> - subnet: 138.250.0.0/15
> - subnet: 138.48.0.0/16
> - subnet: 139.165.0.0/16
> - subnet: 140.109.0.0/16
> - subnet: 143.225.0.0/16
> - subnet: 155.245.0.0/16
> - subnet: 160.80.0.0/16
> - subnet: 161.106.0.0/16
> - subnet: 192.16.124.0/22
> - subnet: 192.38.0.0/17
> - subnet: 192.41.132.0/22
> - subnet: 192.42.42.0/23
> - subnet: 193.1.0.0/16
> - subnet: 193.138.2.0/24
> - subnet: 193.196.0.0/15
> - subnet: 193.166.0.0/15
> - subnet: 193.136.0.0/15
> - subnet: 193.166.0.0/15
> - subnet: 193.204.0.0/15
> - subnet: 193.226.0.0/19
> - subnet: 194.29.176.0/22
> - subnet: 194.167.0.0/16
> - subnet: 194.254.0.0/16
> - subnet: 195.130.124.0/22
> - subnet: 203.110.240.0/24
> - subnet: 212.51.208.0/20
> - subnet: 213.73.32.0/19
> - subnet: 213.131.0.0/19
> - subnet: 136.159.0.0/16
> - subnet: 132.170.0.0/16
> - subnet: 132.181.0.0/16
> - subnet: 133.0.0.0/8
> - subnet: 203.0.0.0/8
> - subnet: 198.82.0.0/16
> - subnet: 200.0.0.0/8
> - subnet: 192.107.171.0/24
> - subnet: 140.112.0.0/12
> - subnet: 140.123.0.0/16
> - subnet: 142.103.0.0/16
> - subnet: 143.89.0.0/16
> - subnet: 139.78.0.0/16
> - subnet: 155.246.0.0/16
> - subnet: 156.56.0.0/16
> - subnet: 156.62.0.0/16
> - subnet: 157.92.0.0/16
> - subnet: 169.226.0.0/16
> - subnet: 165.91.0.0/16
> - subnet: 165.230.0.0/16
> - subnet: 192.1.0.0/16
> - subnet: 192.12.33.0/24
> - subnet: 169.229.0.0/16
> - subnet: 141.219.0.0/16
> # these belong to a too big block
> - subnet: 141.11.0.162
> - subnet: 141.20.103.211
>
>
>
> On Thursday, August 9, 2012 10:21:03 PM UTC+2, Kate wrote:
>>
>>
>> I did that but don't think it will catch them all.
>>
>> I had a list of 100 individual ones, see below. Can you recognize subnets 
>> in them?
>> blacklist:
>> - subnet: 82.179.176.44
>> - subnet: 83.230.127.124
>> - subnet: 88.2.234.60
>> - subnet: 128.10.19.53
>> - subnet: 128.84.154.45
>> - subnet: 128.42.142.44
>> - subnet: 128.36.233.154
>> - subnet: 128.111.52.59
>> - subnet: 128.114.63.64
>> - subnet: 128.138.207.45
>> - subnet: 128.227.150.12
>> - subnet: 128.208.4.198
>> - subnet: 128.151.65.101
>> - subnet: 128.223.8.112
>> - subnet: 128.232.103.201
>> - subnet: 129.10.120.194
>> - subnet: 129.15.78.30
>> - subnet: 129.74.74.20
>> - subnet: 129.82.12.188
>> - subnet: 129.93.229.139
>> - subnet: 129.97.74.14
>> - subnet: 129.108.202.11
>> - subnet: 129.130.252.140
>> - subnet: 129.237.161.194
>> - subnet: 130.37.193.143
>> - subnet: 130.83.166.243
>> - subnet: 130.104.72.213
>> - subnet: 130.216.1.22
>> - subnet: 130.253.21.123
>> - subnet: 130.195.4.68
>> - subnet: 130.237.50.125
>> - subnet: 131.179.150.72
>> - subnet: 131.188.44.102
>> - subnet: 132.65.240.100
>> - subnet: 132.72.23.10
>> - subnet: 132.170.3.32
>> - subnet: 132.181.10.56
>> - subnet: 133.1.74.163
>> - subnet: 133.15.59.2
>> - subnet: 133.68.253.242
>> - subnet: 134.151.255.181
>> - subnet: 138.4.0.120
>> - subnet: 138.251.214.78
>> - subnet: 136.159.220.40
>> - subnet: 138.48.3.202
>> - subnet: 139.78.141.245
>> - subnet: 139.165.12.211
>> - subnet: 140.109.17.181
>> - subnet: 140.112.107.82
>> - subnet: 140.123.230.248
>> - subnet: 141.11.0.162
>> - subnet: 141.20.103.211
>> - subnet: 141.219.252.133
>> - subnet: 142.103.2.2
>> - subnet: 143.89.49.73
>> - subnet: 143.225.229.238
>> - subnet: 155.245.47.225
>> - subnet: 155.246.12.163
>> - subnet: 156.56.250.226
>> - subnet: 156.62.231.244
>> - subnet: 157.92.44.101
>> - subnet: 160.80.221.39
>> - subnet: 161.106.240.19
>> - subnet: 169.226.40.2
>> - subnet:  169.229.50.15
>> - subnet: 165.91.55.8
>> - subnet: 165.230.49.115
>> - 

Re: [google-appengine] How can I block curl requests

[Kate]

Terrific Alex Thank you

On Thursday, August 9, 2012 5:32:03 PM UTC-4, alex wrote:
>
> A lot of those IPs are assigned to universities, like almost literally all 
> of them. More than 50% are US universities. This really looks like a big 
> distributed bot network to me.
>
> Anyway, here you go (some IPs are from the same net block so there are 
> less than 100 entries):
>
>
> - subnet: 82.179.176.0/20
> - subnet: 83.230.96.0/19
> - subnet: 88.2.0.0/16
> - subnet: 128.10.0.0/16
> - subnet: 128.84.0.0/16
> - subnet: 128.42.0.0/16
> - subnet: 128.36.0.0/16
> - subnet: 128.111.0.0/16
> - subnet: 128.114.0.0/16
> - subnet: 128.138.0.0/16
> - subnet: 128.227.0.0/16
> - subnet: 128.208.0.0/16
> - subnet: 128.151.0.0/16
> - subnet: 128.223.0.0/16
> - subnet: 128.232.0.0/16
> - subnet: 129.10.0.0/16
> - subnet: 129.15.0.0/16
> - subnet: 129.74.0.0/16
> - subnet: 129.82.0.0/16
> - subnet: 129.93.0.0/16
> - subnet: 129.97.0.0/16
> - subnet: 129.108.0.0/16
> - subnet: 129.130.0.0/16
> - subnet: 129.237.0.0/16
> - subnet: 130.37.0.0/16
> - subnet: 130.83.0.0/16
> - subnet: 130.104.0.0/16
> - subnet: 130.216.0.0/16
> - subnet: 130.253.0.0/16
> - subnet: 130.195.4.0/24
> - subnet: 130.237.0.0/18
> - subnet: 131.179.0.0/16
> - subnet: 131.188.0.0/16
> - subnet: 132.64.0.0/13
> - subnet: 132.72.0.0/14
> - subnet: 134.151.0.0/16
> - subnet: 138.4.0.0/16
> - subnet: 138.250.0.0/15
> - subnet: 138.48.0.0/16
> - subnet: 139.165.0.0/16
> - subnet: 140.109.0.0/16
> - subnet: 143.225.0.0/16
> - subnet: 155.245.0.0/16
> - subnet: 160.80.0.0/16
> - subnet: 161.106.0.0/16
> - subnet: 192.16.124.0/22
> - subnet: 192.38.0.0/17
> - subnet: 192.41.132.0/22
> - subnet: 192.42.42.0/23
> - subnet: 193.1.0.0/16
> - subnet: 193.138.2.0/24
> - subnet: 193.196.0.0/15
> - subnet: 193.166.0.0/15
> - subnet: 193.136.0.0/15
> - subnet: 193.166.0.0/15
> - subnet: 193.204.0.0/15
> - subnet: 193.226.0.0/19
> - subnet: 194.29.176.0/22
> - subnet: 194.167.0.0/16
> - subnet: 194.254.0.0/16
> - subnet: 195.130.124.0/22
> - subnet: 203.110.240.0/24
> - subnet: 212.51.208.0/20
> - subnet: 213.73.32.0/19
> - subnet: 213.131.0.0/19
> - subnet: 136.159.0.0/16
> - subnet: 132.170.0.0/16
> - subnet: 132.181.0.0/16
> - subnet: 133.0.0.0/8
> - subnet: 203.0.0.0/8
> - subnet: 198.82.0.0/16
> - subnet: 200.0.0.0/8
> - subnet: 192.107.171.0/24
> - subnet: 140.112.0.0/12
> - subnet: 140.123.0.0/16
> - subnet: 142.103.0.0/16
> - subnet: 143.89.0.0/16
> - subnet: 139.78.0.0/16
> - subnet: 155.246.0.0/16
> - subnet: 156.56.0.0/16
> - subnet: 156.62.0.0/16
> - subnet: 157.92.0.0/16
> - subnet: 169.226.0.0/16
> - subnet: 165.91.0.0/16
> - subnet: 165.230.0.0/16
> - subnet: 192.1.0.0/16
> - subnet: 192.12.33.0/24
> - subnet: 169.229.0.0/16
> - subnet: 141.219.0.0/16
> # these belong to a too big block
> - subnet: 141.11.0.162
> - subnet: 141.20.103.211
>
>
>
> On Thursday, August 9, 2012 10:21:03 PM UTC+2, Kate wrote:
>>
>>
>> I did that but don't think it will catch them all.
>>
>> I had a list of 100 individual ones, see below. Can you recognize subnets 
>> in them?
>> blacklist:
>> - subnet: 82.179.176.44
>> - subnet: 83.230.127.124
>> - subnet: 88.2.234.60
>> - subnet: 128.10.19.53
>> - subnet: 128.84.154.45
>> - subnet: 128.42.142.44
>> - subnet: 128.36.233.154
>> - subnet: 128.111.52.59
>> - subnet: 128.114.63.64
>> - subnet: 128.138.207.45
>> - subnet: 128.227.150.12
>> - subnet: 128.208.4.198
>> - subnet: 128.151.65.101
>> - subnet: 128.223.8.112
>> - subnet: 128.232.103.201
>> - subnet: 129.10.120.194
>> - subnet: 129.15.78.30
>> - subnet: 129.74.74.20
>> - subnet: 129.82.12.188
>> - subnet: 129.93.229.139
>> - subnet: 129.97.74.14
>> - subnet: 129.108.202.11
>> - subnet: 129.130.252.140
>> - subnet: 129.237.161.194
>> - subnet: 130.37.193.143
>> - subnet: 130.83.166.243
>> - subnet: 130.104.72.213
>> - subnet: 130.216.1.22
>> - subnet: 130.253.21.123
>> - subnet: 130.195.4.68
>> - subnet: 130.237.50.125
>> - subnet: 131.179.150.72
>> - subnet: 131.188.44.102
>> - subnet: 132.65.240.100
>> - subnet: 132.72.23.10
>> - subnet: 132.170.3.32
>> - subnet: 132.181.10.56
>> - subnet: 133.1.74.163
>> - subnet: 133.15.59.2
>> - subnet: 133.68.253.242
>> - subnet: 134.151.255.181
>> - subnet: 138.4.0.120
>> - subnet: 138.251.214.78
>> - subnet: 136.159.220.40
>> - subnet: 138.48.3.202
>> - subnet: 139.78.141.245
>> - subnet: 139.165.12.211
>> - subnet: 140.109.17.181
>> - subnet: 140.112.107.82
>> - subnet: 140.123.230.248
>> - subnet: 141.11.0.162
>> - subnet: 141.20.103.211
>> - subnet: 141.219.252.133
>> - subnet: 142.103.2.2
>> - subnet: 143.89.49.73
>> - subnet: 143.225.229.238
>> - subnet: 155.245.47.225
>> - subnet: 155.246.12.163
>> - subnet: 156.56.250.226
>> - subnet: 156.62.231.244
>> - subnet: 157.92.44.101
>> - subnet: 160.80.221.39
>> - subnet: 161.106.240.19
>> - subnet: 169.226.40.2
>> - subnet:  169.229.50.15
>> - subnet: 165.91.55.8
>> - subnet: 165.230.49.115
>> - subnet: 192.1.249.138
>> - subnet: 192.12.33.102
>> - subnet: 192.16.125.11
>> - su

[google-appengine] Re: Anybody interested in a Datastore Manager for GAE?

[Emanuele Ziglioli]

it looks really good.

I've used the evaluation of AppWrench and have found very useful the 
ability to edit both local and remote store. I find painful you can't add 
fields to an existing entity from the official web console (or can you?).

Haven't been able to run the profiler but I'd love to have tools like 
AppWrench in order to profile memory usage and other parameters that are 
unique to the GAE's production environment and that are not currently 
covered by AppStats.
Although, that'd be outside the focus of your project I suspect.

On Thursday, 9 August 2012 11:24:07 UTC+12, Backpack wrote:
>
> Here is a mockup of what I envision: 
>
> http://georgenava.appspot.com/static/images/datamanager.png 
>
> It fits better the table model of MySQL but right now it works with 
> the datastore just fine. 
>
> Inline editing, SQL console, import, export, and all the stuff, will 
> be a huge undertaking, that's why I want to measure initial response. 
>
> Thanks for your feedback. 
>
>
> On Aug 8, 6:56 pm, "Drake"  wrote: 
> > Possibly. The Admin Console does suck, I would be happy to look at some 
> > screen shots, see what you bring to the table.  We'd rather pay once. 
> > 
> > When we looked in to this, the challenge was really that the datastore 
> calls 
> > add up fast. 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > -Original Message- 
> > > From: google-a...@googlegroups.com  
> > > [mailto:google- 
> > > appe...@googlegroups.com ] On Behalf Of Backpack 
> > > Sent: Wednesday, August 08, 2012 2:42 PM 
> > > To: Google App Engine 
> > > Subject: [google-appengine] Anybody interested in a Datastore Manager 
> for 
> > > GAE? 
> > 
> > > Something like phpMyAdmin for MySQL but adapted to the datastore. 
> > > If so, answer these questions: 
> > 
> > > - What datastore: db, ndb or SQL? 
> > > - How much would you pay for that? 
> > > - Pay once use forever with yearly versions?  ~$100/ver 
> > > - or pay monthly with free updates? ~$10/mo 
> > > - web based or desktop app? 
> > 
> > > I am thinking on doing one with the latest HTML,CSS,JS stuff (sorry 
> > > IE) and just wanted to see if there was any interest in a tool like 
> that. 
> > The 
> > > data viewer and data admin stuff offered by gae are limited in 
> > functionality. 
> > 
> > > Thanks for your time in answering the questions. 
> > 
> > > -- 
> > > 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-a...@googlegroups.com. 
>
> > > To unsubscribe from this group, send email to google- 
> > > appengine+...@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/-/mA4PXJ42E5gJ.
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] Can you tweak the memacache timeout

[Emanuele Ziglioli]

Hi,

this morning we're experiencing repetitive memcache errors. I see a 
"LogAndContinueErrorHandler" so requests don't fail but they take an awful 
amount of time to be fullfilled.
Is there any way to force a maximum response time for memcache (something 
like 50ms?).
I will profile it using appstat


com.google.appengine.api.memcache.LogAndContinueErrorHandler 
handleServiceError: Service error in memcache
com.google.appengine.api.memcache.MemcacheServiceException: Memcache 
getIdentifiables: exception getting multiple keys
at 
com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandler.handleApiProxyException(MemcacheServiceApiHelper.java:76)
at 
com.google.appengine.api.memcache.MemcacheServiceApiHelper$1.absorbParentException(MemcacheServiceApiHelper.java:120)
at 
com.google.appengine.api.utils.FutureWrapper.handleParentException(FutureWrapper.java:53)
at 
com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:92)
at 
com.google.appengine.api.memcache.MemcacheServiceImpl.quietGet(MemcacheServiceImpl.java:28)
at 
com.google.appengine.api.memcache.MemcacheServiceImpl.getIdentifiables(MemcacheServiceImpl.java:61)
at 
com.googlecode.objectify.cache.EntityMemcache.getAll(EntityMemcache.java:215)
at 
com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:253)
at 
com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:216)
at 
com.googlecode.objectify.cache.CachingDatastoreService.get(CachingDatastoreService.java:137)
at siena.gae.GaePersistenceManager.get(GaePersistenceManager.java:2146)
at siena.core.batch.BaseBatch.get(BaseBatch.java:60)

-- 
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/-/a6s1gdXVHUMJ.
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: Can you tweak the memacache timeout

[Emanuele Ziglioli]

My same question on SO: 
http://stackoverflow.com/questions/11893308/can-you-tweak-gaes-memcache-timeout
Thanks

On Friday, 10 August 2012 11:06:53 UTC+12, Emanuele Ziglioli wrote:
>
> Hi,
>
> this morning we're experiencing repetitive memcache errors. I see a 
> "LogAndContinueErrorHandler" so requests don't fail but they take an awful 
> amount of time to be fullfilled.
> Is there any way to force a maximum response time for memcache (something 
> like 50ms?).
> I will profile it using appstat
>
>
> com.google.appengine.api.memcache.LogAndContinueErrorHandler 
> handleServiceError: Service error in memcache
> com.google.appengine.api.memcache.MemcacheServiceException: Memcache 
> getIdentifiables: exception getting multiple keys
>   at 
> com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandler.handleApiProxyException(MemcacheServiceApiHelper.java:76)
>   at 
> com.google.appengine.api.memcache.MemcacheServiceApiHelper$1.absorbParentException(MemcacheServiceApiHelper.java:120)
>   at 
> com.google.appengine.api.utils.FutureWrapper.handleParentException(FutureWrapper.java:53)
>   at 
> com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:92)
>   at 
> com.google.appengine.api.memcache.MemcacheServiceImpl.quietGet(MemcacheServiceImpl.java:28)
>   at 
> com.google.appengine.api.memcache.MemcacheServiceImpl.getIdentifiables(MemcacheServiceImpl.java:61)
>   at 
> com.googlecode.objectify.cache.EntityMemcache.getAll(EntityMemcache.java:215)
>   at 
> com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:253)
>   at 
> com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:216)
>   at 
> com.googlecode.objectify.cache.CachingDatastoreService.get(CachingDatastoreService.java:137)
>   at siena.gae.GaePersistenceManager.get(GaePersistenceManager.java:2146)
>   at siena.core.batch.BaseBatch.get(BaseBatch.java:60)
>
>

-- 
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/-/yvLiqM4uegIJ.
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: backend termination question

[jon]

Thanks for the reply Takashi.

App Engine sometimes needs to stop Backend instances for various 
> reasons other than your manual intervention.


May I ask if this is the definite cause for "Process terminated because the 
backend took too long to shutdown." , or is it something that you thought 
might have explained it?

I'm asking to determine if this is something that I can fix and forget, or 
if it's something that can happen every now and then despite handling the 
shutdown case properly?
 

> You can write a shutdown 
> hook to do something for your halfway job within the 30 seconds 
> window. 
>

We completely forgot about the shutdown case. Will handle it properly.
 

>
> -- Takashi 
>
> On Tue, Aug 7, 2012 at 6:11 PM, jon > 
> wrote: 
> > Can Google please respond to this? We also got  Process terminated 
> because 
> > the backend took too long to shutdown.  on the 17 min mark. 
> > 
> > -- 
> > 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/-/bTJQ9OLKuxIJ. 
> > 
> > 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. 
>
>
>
> -- 
> Takashi Matsuo | Developer Advocate | tma...@google.com  
>

-- 
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/-/MPFGbkGMsl8J.
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] Can you tweak the memacache timeout

[Drake]

I have asked for this in the past. When MemCache starts acting up we log it
and switch to 100% our own "memcache like server" for 20 minutes but that is
less than ideal.

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Emanuele Ziglioli
Sent: Thursday, August 09, 2012 4:07 PM
To: google-appengine@googlegroups.com
Subject: [google-appengine] Can you tweak the memacache timeout

 

Hi,

 

this morning we're experiencing repetitive memcache errors. I see a
"LogAndContinueErrorHandler" so requests don't fail but they take an awful
amount of time to be fullfilled.

Is there any way to force a maximum response time for memcache (something
like 50ms?).

I will profile it using appstat

 

 

com.google.appengine.api.memcache.LogAndContinueErrorHandler
handleServiceError: Service error in memcache
com.google.appengine.api.memcache.MemcacheServiceException: Memcache
getIdentifiables: exception getting multiple keys
   at
com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandle
r.handleApiProxyException(MemcacheServiceApiHelper.java:76)
   at
com.google.appengine.api.memcache.MemcacheServiceApiHelper$1.absorbParentExc
eption(MemcacheServiceApiHelper.java:120)
   at
com.google.appengine.api.utils.FutureWrapper.handleParentException(FutureWra
pper.java:53)
   at
com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:92)
   at
com.google.appengine.api.memcache.MemcacheServiceImpl.quietGet(MemcacheServi
ceImpl.java:28)
   at
com.google.appengine.api.memcache.MemcacheServiceImpl.getIdentifiables(Memca
cheServiceImpl.java:61)
   at
com.googlecode.objectify.cache.EntityMemcache.getAll(EntityMemcache.java:215
)
   at
com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsync
DatastoreService.java:253)
   at
com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsync
DatastoreService.java:216)
   at
com.googlecode.objectify.cache.CachingDatastoreService.get(CachingDatastoreS
ervice.java:137)
   at
siena.gae.GaePersistenceManager.get(GaePersistenceManager.java:2146)
   at siena.core.batch.BaseBatch.get(BaseBatch.java:60)

-- 
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/-/a6s1gdXVHUMJ.
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: Backend performance, compared

[Kristopher Giesing]

That would work up until your data got evicted at the wrong time...

Though this gets me thinking: it would be really, really nice for many 
applications to have a *guaranteed* memcached-style in-memory table that 
you could use to share data between instances (and between FE/BE).  Unlike 
memcached there would be no automatic management; instead you would 
manually add/remove items to stay within a hard limit (or put()s would 
fail).  The hard limit could depend on configuration and maybe you could 
pay for more if you needed it.

- Kris

On Thursday, August 9, 2012 7:38:40 AM UTC-7, Hernan Liendo wrote:
>
> *
> On the other hand, I think you could simplify a little your scoring 
> solution. What if you hold user’s scores on sharded MemCache entries and 
> after a while you get all of them and save the result on the DataStore?*
>
>

-- 
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/-/3V5Fp6ul8dsJ.
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] How can I block curl requests

[Kate]

Done,

Actually I have some more. Can you "subnet" any of these? all planet-lab 
ones

- subnet: 134.117.226.181
- subnet: 147.229.10.250
- subnet: 206.23.240.29
- subnet: 160.193.163.106
- subnet: 138.246.99.249
- subnet: 129.242.19.197
- subnet: 206.12.16.154
- subnet: 160.193.163.106
- subnet: 152.3.138.6
- subnet: 195.37.16.121

I am up to 100 now because of these individual ones.


On Thursday, August 9, 2012 5:37:41 PM UTC-4, alex wrote:
>
> Actually, scratch last three lines (starting from # these belong to...) 
> and replace with
>
> - subnet: 141.0.0.0/8
>
>
> On Thursday, August 9, 2012 11:32:03 PM UTC+2, alex wrote:
>>
>> A lot of those IPs are assigned to universities, like almost literally 
>> all of them. More than 50% are US universities. This really looks like a 
>> big distributed bot network to me.
>>
>> Anyway, here you go (some IPs are from the same net block so there are 
>> less than 100 entries):
>>
>>
>> - subnet: 82.179.176.0/20
>> - subnet: 83.230.96.0/19
>> - subnet: 88.2.0.0/16
>> - subnet: 128.10.0.0/16
>> - subnet: 128.84.0.0/16
>> - subnet: 128.42.0.0/16
>> - subnet: 128.36.0.0/16
>> - subnet: 128.111.0.0/16
>> - subnet: 128.114.0.0/16
>> - subnet: 128.138.0.0/16
>> - subnet: 128.227.0.0/16
>> - subnet: 128.208.0.0/16
>> - subnet: 128.151.0.0/16
>> - subnet: 128.223.0.0/16
>> - subnet: 128.232.0.0/16
>> - subnet: 129.10.0.0/16
>> - subnet: 129.15.0.0/16
>> - subnet: 129.74.0.0/16
>> - subnet: 129.82.0.0/16
>> - subnet: 129.93.0.0/16
>> - subnet: 129.97.0.0/16
>> - subnet: 129.108.0.0/16
>> - subnet: 129.130.0.0/16
>> - subnet: 129.237.0.0/16
>> - subnet: 130.37.0.0/16
>> - subnet: 130.83.0.0/16
>> - subnet: 130.104.0.0/16
>> - subnet: 130.216.0.0/16
>> - subnet: 130.253.0.0/16
>> - subnet: 130.195.4.0/24
>> - subnet: 130.237.0.0/18
>> - subnet: 131.179.0.0/16
>> - subnet: 131.188.0.0/16
>> - subnet: 132.64.0.0/13
>> - subnet: 132.72.0.0/14
>> - subnet: 134.151.0.0/16
>> - subnet: 138.4.0.0/16
>> - subnet: 138.250.0.0/15
>> - subnet: 138.48.0.0/16
>> - subnet: 139.165.0.0/16
>> - subnet: 140.109.0.0/16
>> - subnet: 143.225.0.0/16
>> - subnet: 155.245.0.0/16
>> - subnet: 160.80.0.0/16
>> - subnet: 161.106.0.0/16
>> - subnet: 192.16.124.0/22
>> - subnet: 192.38.0.0/17
>> - subnet: 192.41.132.0/22
>> - subnet: 192.42.42.0/23
>> - subnet: 193.1.0.0/16
>> - subnet: 193.138.2.0/24
>> - subnet: 193.196.0.0/15
>> - subnet: 193.166.0.0/15
>> - subnet: 193.136.0.0/15
>> - subnet: 193.166.0.0/15
>> - subnet: 193.204.0.0/15
>> - subnet: 193.226.0.0/19
>> - subnet: 194.29.176.0/22
>> - subnet: 194.167.0.0/16
>> - subnet: 194.254.0.0/16
>> - subnet: 195.130.124.0/22
>> - subnet: 203.110.240.0/24
>> - subnet: 212.51.208.0/20
>> - subnet: 213.73.32.0/19
>> - subnet: 213.131.0.0/19
>> - subnet: 136.159.0.0/16
>> - subnet: 132.170.0.0/16
>> - subnet: 132.181.0.0/16
>> - subnet: 133.0.0.0/8
>> - subnet: 203.0.0.0/8
>> - subnet: 198.82.0.0/16
>> - subnet: 200.0.0.0/8
>> - subnet: 192.107.171.0/24
>> - subnet: 140.112.0.0/12
>> - subnet: 140.123.0.0/16
>> - subnet: 142.103.0.0/16
>> - subnet: 143.89.0.0/16
>> - subnet: 139.78.0.0/16
>> - subnet: 155.246.0.0/16
>> - subnet: 156.56.0.0/16
>> - subnet: 156.62.0.0/16
>> - subnet: 157.92.0.0/16
>> - subnet: 169.226.0.0/16
>> - subnet: 165.91.0.0/16
>> - subnet: 165.230.0.0/16
>> - subnet: 192.1.0.0/16
>> - subnet: 192.12.33.0/24
>> - subnet: 169.229.0.0/16
>> - subnet: 141.219.0.0/16
>> # these belong to a too big block
>> - subnet: 141.11.0.162
>> - subnet: 141.20.103.211
>>
>>
>>
>> On Thursday, August 9, 2012 10:21:03 PM UTC+2, Kate wrote:
>>>
>>>
>>> I did that but don't think it will catch them all.
>>>
>>> I had a list of 100 individual ones, see below. Can you recognize 
>>> subnets in them?
>>> blacklist:
>>> - subnet: 82.179.176.44
>>> - subnet: 83.230.127.124
>>> - subnet: 88.2.234.60
>>> - subnet: 128.10.19.53
>>> - subnet: 128.84.154.45
>>> - subnet: 128.42.142.44
>>> - subnet: 128.36.233.154
>>> - subnet: 128.111.52.59
>>> - subnet: 128.114.63.64
>>> - subnet: 128.138.207.45
>>> - subnet: 128.227.150.12
>>> - subnet: 128.208.4.198
>>> - subnet: 128.151.65.101
>>> - subnet: 128.223.8.112
>>> - subnet: 128.232.103.201
>>> - subnet: 129.10.120.194
>>> - subnet: 129.15.78.30
>>> - subnet: 129.74.74.20
>>> - subnet: 129.82.12.188
>>> - subnet: 129.93.229.139
>>> - subnet: 129.97.74.14
>>> - subnet: 129.108.202.11
>>> - subnet: 129.130.252.140
>>> - subnet: 129.237.161.194
>>> - subnet: 130.37.193.143
>>> - subnet: 130.83.166.243
>>> - subnet: 130.104.72.213
>>> - subnet: 130.216.1.22
>>> - subnet: 130.253.21.123
>>> - subnet: 130.195.4.68
>>> - subnet: 130.237.50.125
>>> - subnet: 131.179.150.72
>>> - subnet: 131.188.44.102
>>> - subnet: 132.65.240.100
>>> - subnet: 132.72.23.10
>>> - subnet: 132.170.3.32
>>> - subnet: 132.181.10.56
>>> - subnet: 133.1.74.163
>>> - subnet: 133.15.59.2
>>> - subnet: 133.68.253.242
>>> - subnet: 134.151.255.181
>>> - subnet: 138.4.0.120
>>> - subnet: 138.251.214.78
>>> - subnet: 136.159.220.40
>>> - subnet: 138.4

Re: [google-appengine] Can you tweak the memacache timeout

[Emanuele Ziglioli]

I see in 
/**
 * Waits if necessary for at most the given time for the computation
 * to complete, and then retrieves its result, if available.
 *
 * @param timeout the maximum time to wait
 * @param unit the time unit of the timeout argument
 * @return the computed result
 * @throws CancellationException if the computation was cancelled
 * @throws ExecutionException if the computation threw an
 * exception
 * @throws InterruptedException if the current thread was interrupted
 * while waiting
 * @throws TimeoutException if the wait timed out
 */
V get(long timeout, TimeUnit unit)
throws InterruptedException, ExecutionException, TimeoutException;
..


Also in com.google.appengine.tools.development.TimedFuture.java

  private long getMillisRemaining() {
return Math.max(0, deadlineTime - clock.getCurrentTime());
  }



So there may be a parameter somewhere we could set

On Friday, 10 August 2012 12:50:04 UTC+12, Brandon Wirtz wrote:
>
> I have asked for this in the past. When MemCache starts acting up we log 
> it and switch to 100% our own “memcache like server” for 20 minutes but 
> that is less than ideal.
>
>  
>
> *From:* google-a...@googlegroups.com  [mailto:
> google-a...@googlegroups.com ] *On Behalf Of *Emanuele 
> Ziglioli
> *Sent:* Thursday, August 09, 2012 4:07 PM
> *To:* google-a...@googlegroups.com 
> *Subject:* [google-appengine] Can you tweak the memacache timeout
>
>  
>
> Hi,
>
>  
>
> this morning we're experiencing repetitive memcache errors. I see a 
> "LogAndContinueErrorHandler" so requests don't fail but they take an awful 
> amount of time to be fullfilled.
>
> Is there any way to force a maximum response time for memcache (something 
> like 50ms?).
>
> I will profile it using appstat
>
>  
>
>  
>
> com.google.appengine.api.memcache.LogAndContinueErrorHandler 
> handleServiceError: Service error in memcache
>
> com.google.appengine.api.memcache.MemcacheServiceException: Memcache 
> getIdentifiables: exception getting multiple keys
>
>at 
> com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandler.handleApiProxyException(MemcacheServiceApiHelper.java:76)
>
>at 
> com.google.appengine.api.memcache.MemcacheServiceApiHelper$1.absorbParentException(MemcacheServiceApiHelper.java:120)
>
>at 
> com.google.appengine.api.utils.FutureWrapper.handleParentException(FutureWrapper.java:53)
>
>at 
> com.google.appengine.api.utils.FutureWrapper.get(FutureWrapper.java:92)
>
>at 
> com.google.appengine.api.memcache.MemcacheServiceImpl.quietGet(MemcacheServiceImpl.java:28)
>
>at 
> com.google.appengine.api.memcache.MemcacheServiceImpl.getIdentifiables(MemcacheServiceImpl.java:61)
>
>at 
> com.googlecode.objectify.cache.EntityMemcache.getAll(EntityMemcache.java:215)
>
>at 
> com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:253)
>
>at 
> com.googlecode.objectify.cache.CachingAsyncDatastoreService.get(CachingAsyncDatastoreService.java:216)
>
>at 
> com.googlecode.objectify.cache.CachingDatastoreService.get(CachingDatastoreService.java:137)
>
>at siena.gae.GaePersistenceManager.get(GaePersistenceManager.java:2146)
>
>at siena.core.batch.BaseBatch.get(BaseBatch.java:60)
>
> -- 
> 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/-/a6s1gdXVHUMJ.
> 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/-/3730-Wel47UJ.
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] Can you tweak the memacache timeout

[Emanuele Ziglioli]

I'm doing some experiments 
on com.google.appengine.api.memcache.MemcacheServiceImpl

  private static  T quietGet(Future future) {
try {
//  return future.get();
  return future.get( 100, TimeUnit.MILLISECONDS);
} catch (TimeoutException ex) {
//  throw new ExecutionException(createDeadlineException());
  logger.log(Level.WARNING, ex.getMessage() + " " + future );
  return null;
}
catch (InterruptedException e) {
  Thread.currentThread().interrupt();
  throw new MemcacheServiceException("Unexpected failure", e);
} catch (ExecutionException e) {
  Throwable cause = e.getCause();
  if (cause instanceof RuntimeException) {
throw (RuntimeException) cause;
  } else if (cause instanceof Error) {
throw (Error) cause;
  } else {
throw new UndeclaredThrowableException(cause);
  }
}
  }



I'm not sure if it's working 100% yet, the web app seems to open faster, 
but there are still errors.
I'm sure something can be improved around there
I'm off next week, have fun




-- 
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/-/aKrs3-BElJwJ.
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] Unique Integer ID for a non primary key field for Entities in Google App Engine

[Neo]

Hi Michael,
Thanks. That was really useful.

-- 
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/-/ElgNXPZHlkQJ.
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.