[google-appengine] Poor connectivity to ghs-vip-any-* for SSL custom domains, et al
We are having a painful time accessing https://loudr.fm from our SF office. Many connections seem to timeout. Here is a traceroute: $ traceroute -w 1 loudr.fm traceroute to loudr.fm (72.14.248.104), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.466 ms 0.280 ms 0.409 ms 2 76-14-68-1.sf-cable.astound.net (76.14.68.1) 11.081 ms 25.822 ms 9.019 ms 3 104.220.254.17 (104.220.254.17) 23.299 ms 14.741 ms 9.966 ms 4 76-14-93-222.sf-cable.astound.net (76.14.93.222) 30.097 ms 76-14-93-218.sf-cable.astound.net (76.14.93.218) 23.407 ms 76-14-93-222.sf-cable.astound.net (76.14.93.222) 33.639 ms 5 cr1-wsache-a-be-100.bb.spectrumnet.us (208.76.187.33) 18.994 ms 32.843 ms 30.177 ms 6 cr1-55smarket-te-0-0-0-10.bb.spectrumnet.us (208.76.185.28) 30.690 ms cr1-55smarket-te-0-0-0-8.bb.spectrumnet.us (208.76.185.24) 29.779 ms cr1-55smarket-te-0-0-0-19.bb.spectrumnet.us (208.76.185.88) 19.283 ms 7 cr1-9greatoaks-te-0-7-0-7.bb.spectrumnet.us (208.76.185.58) 21.689 ms 18.598 ms cr1-9greatoaks-te-0-7-0-8.bb.spectrumnet.us (208.76.185.60) 30.415 ms 8 72.14.204.109 (72.14.204.109) 36.941 ms 50.637 ms 43.910 ms 9 209.85.249.5 (209.85.249.5) 31.709 ms 20.943 ms 209.85.249.3 (209.85.249.3) 19.013 ms 10 209.85.246.20 (209.85.246.20) 21.758 ms 209.85.246.38 (209.85.246.38) 51.160 ms 57.971 ms 11 72.14.232.63 (72.14.232.63) 51.038 ms 216.239.49.198 (216.239.49.198) 39.980 ms 72.14.232.63 (72.14.232.63) 40.313 ms 12 216.239.40.146 (216.239.40.146) 55.694 ms 72.14.233.140 (72.14.233.140) 35.166 ms 64.233.175.36 (64.233.175.36) 50.961 ms 13 66.249.94.109 (66.249.94.109) 40.781 ms 216.239.46.175 (216.239.46.175) 42.409 ms 216.239.41.44 (216.239.41.44) 35.814 ms *14 * * ** 15 ghs-vip-any-c866.ghs-ssl.googlehosted.com (72.14.248.104) 35.157 ms 36.770 ms 38.434 ms *Compare to a pingdom traceroute:* http://tools.pingdom.com/ping/default.aspx?target=loudr.fmo=1id=8350420 We're not sure why this happening, but I know that connecting to appspot.com directly doesn't suffer from any of the same problems. Any ideas as to how to resolve this issue? *Our SSL Domain Setup:* SNI + VIP: 866 ALIAS to ghs-svc-https-c866.ghs-ssl.googlehosted.com Any help is wildly appreciated. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/34db0721-349b-4452-bf96-efea2f3afb42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Poor connectivity to ghs-vip-any-* for SSL custom domains, et al
*Time to first byte for https://loudr.fm/* D914B0EA31C7BF890D60EB1C20474640/dist/vendor/bundle.js 9.01s!! *Time to first byte for same resource, https://rdscover.appspot.com* /D914B0EA31C7BF890D60EB1C20474640/dist/vendor/bundle.js 685ms!! This is a huge discrepancy, and I can't find the bottleneck. On Friday, July 31, 2015 at 3:38:54 PM UTC-7, Josh Whelchel (Loudr) wrote: We are having a painful time accessing https://loudr.fm from our SF office. Many connections seem to timeout. Here is a traceroute: $ traceroute -w 1 loudr.fm traceroute to loudr.fm (72.14.248.104), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.466 ms 0.280 ms 0.409 ms 2 76-14-68-1.sf-cable.astound.net (76.14.68.1) 11.081 ms 25.822 ms 9.019 ms 3 104.220.254.17 (104.220.254.17) 23.299 ms 14.741 ms 9.966 ms 4 76-14-93-222.sf-cable.astound.net (76.14.93.222) 30.097 ms 76-14-93-218.sf-cable.astound.net (76.14.93.218) 23.407 ms 76-14-93-222.sf-cable.astound.net (76.14.93.222) 33.639 ms 5 cr1-wsache-a-be-100.bb.spectrumnet.us (208.76.187.33) 18.994 ms 32.843 ms 30.177 ms 6 cr1-55smarket-te-0-0-0-10.bb.spectrumnet.us (208.76.185.28) 30.690 ms cr1-55smarket-te-0-0-0-8.bb.spectrumnet.us (208.76.185.24) 29.779 ms cr1-55smarket-te-0-0-0-19.bb.spectrumnet.us (208.76.185.88) 19.283 ms 7 cr1-9greatoaks-te-0-7-0-7.bb.spectrumnet.us (208.76.185.58) 21.689 ms 18.598 ms cr1-9greatoaks-te-0-7-0-8.bb.spectrumnet.us (208.76.185.60) 30.415 ms 8 72.14.204.109 (72.14.204.109) 36.941 ms 50.637 ms 43.910 ms 9 209.85.249.5 (209.85.249.5) 31.709 ms 20.943 ms 209.85.249.3 (209.85.249.3) 19.013 ms 10 209.85.246.20 (209.85.246.20) 21.758 ms 209.85.246.38 (209.85.246.38) 51.160 ms 57.971 ms 11 72.14.232.63 (72.14.232.63) 51.038 ms 216.239.49.198 (216.239.49.198) 39.980 ms 72.14.232.63 (72.14.232.63) 40.313 ms 12 216.239.40.146 (216.239.40.146) 55.694 ms 72.14.233.140 (72.14.233.140) 35.166 ms 64.233.175.36 (64.233.175.36) 50.961 ms 13 66.249.94.109 (66.249.94.109) 40.781 ms 216.239.46.175 (216.239.46.175) 42.409 ms 216.239.41.44 (216.239.41.44) 35.814 ms *14 * * ** 15 ghs-vip-any-c866.ghs-ssl.googlehosted.com (72.14.248.104) 35.157 ms 36.770 ms 38.434 ms *Compare to a pingdom traceroute:* http://tools.pingdom.com/ping/default.aspx?target=loudr.fmo=1id=8350420 We're not sure why this happening, but I know that connecting to appspot.com directly doesn't suffer from any of the same problems. Any ideas as to how to resolve this issue? *Our SSL Domain Setup:* SNI + VIP: 866 ALIAS to ghs-svc-https-c866.ghs-ssl.googlehosted.com Any help is wildly appreciated. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/d12c6bf2-bf46-4407-b966-7d87abb95257%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Poor connectivity to ghs-vip-any-* for SSL custom domains, et al
The same resource behind a CDN loads in a snap: *https://app.loudr.fm/*D914B0EA31C7BF890D60EB1C20474640/dist/ vendor/bundle.js https://app.loudr.fm/D914B0EA31C7BF890D60EB1C20474640/dist/vendor/bundle.js On Friday, July 31, 2015 at 4:00:53 PM UTC-7, Josh Whelchel (Loudr) wrote: *Time to first byte for https://loudr.fm/ https://loudr.fm/* D914B0EA31C7BF890D60EB1C20474640/dist/vendor/bundle.js 9.01s!! *Time to first byte for same resource, https://rdscover.appspot.com https://rdscover.appspot.com* /D914B0EA31C7BF890D60EB1C20474640/dist/vendor/bundle.js 685ms!! This is a huge discrepancy, and I can't find the bottleneck. On Friday, July 31, 2015 at 3:38:54 PM UTC-7, Josh Whelchel (Loudr) wrote: We are having a painful time accessing https://loudr.fm from our SF office. Many connections seem to timeout. Here is a traceroute: $ traceroute -w 1 loudr.fm traceroute to loudr.fm (72.14.248.104), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 0.466 ms 0.280 ms 0.409 ms 2 76-14-68-1.sf-cable.astound.net (76.14.68.1) 11.081 ms 25.822 ms 9.019 ms 3 104.220.254.17 (104.220.254.17) 23.299 ms 14.741 ms 9.966 ms 4 76-14-93-222.sf-cable.astound.net (76.14.93.222) 30.097 ms 76-14-93-218.sf-cable.astound.net (76.14.93.218) 23.407 ms 76-14-93-222.sf-cable.astound.net (76.14.93.222) 33.639 ms 5 cr1-wsache-a-be-100.bb.spectrumnet.us (208.76.187.33) 18.994 ms 32.843 ms 30.177 ms 6 cr1-55smarket-te-0-0-0-10.bb.spectrumnet.us (208.76.185.28) 30.690 ms cr1-55smarket-te-0-0-0-8.bb.spectrumnet.us (208.76.185.24) 29.779 ms cr1-55smarket-te-0-0-0-19.bb.spectrumnet.us (208.76.185.88) 19.283 ms 7 cr1-9greatoaks-te-0-7-0-7.bb.spectrumnet.us (208.76.185.58) 21.689 ms 18.598 ms cr1-9greatoaks-te-0-7-0-8.bb.spectrumnet.us (208.76.185.60) 30.415 ms 8 72.14.204.109 (72.14.204.109) 36.941 ms 50.637 ms 43.910 ms 9 209.85.249.5 (209.85.249.5) 31.709 ms 20.943 ms 209.85.249.3 (209.85.249.3) 19.013 ms 10 209.85.246.20 (209.85.246.20) 21.758 ms 209.85.246.38 (209.85.246.38) 51.160 ms 57.971 ms 11 72.14.232.63 (72.14.232.63) 51.038 ms 216.239.49.198 (216.239.49.198) 39.980 ms 72.14.232.63 (72.14.232.63) 40.313 ms 12 216.239.40.146 (216.239.40.146) 55.694 ms 72.14.233.140 (72.14.233.140) 35.166 ms 64.233.175.36 (64.233.175.36) 50.961 ms 13 66.249.94.109 (66.249.94.109) 40.781 ms 216.239.46.175 (216.239.46.175) 42.409 ms 216.239.41.44 (216.239.41.44) 35.814 ms *14 * * ** 15 ghs-vip-any-c866.ghs-ssl.googlehosted.com (72.14.248.104) 35.157 ms 36.770 ms 38.434 ms *Compare to a pingdom traceroute:* http://tools.pingdom.com/ping/default.aspx?target=loudr.fmo=1id=8350420 We're not sure why this happening, but I know that connecting to appspot.com directly doesn't suffer from any of the same problems. Any ideas as to how to resolve this issue? *Our SSL Domain Setup:* SNI + VIP: 866 ALIAS to ghs-svc-https-c866.ghs-ssl.googlehosted.com Any help is wildly appreciated. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/fff77549-49d1-436d-a5bc-c73a8f1ed68e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] cloudstorage library and URLFetch quotas - workaround?
We use Cloud Storage to store large elasticsearch results (from aggregations - so scan+scroll isn't going to work here). To handle these large aggregations in parallel, we store them as multiline JSON dumps that is sourced from a managed vm. As a result, to perform *parallel processing*, many *app engine *instances will open this file at once, and as a result, *hit the URLFetch rate limit* because of this documented limitation: and the calls count against your URL fetch quota, as the library uses the URL Fetch service to interact with Cloud Storage. - https://cloud.google.com/appengine/docs/python/googlecloudstorageclient/ *Here's the resulting exception:* https://lh3.googleusercontent.com/-WbU1UiwCB2s/VbkWhCRDMjI/AH0/Ta3WBGEC0n0/s1600/Screenshot%2B2015-07-28%2B17.07.40.png *Here's the code that opens the file:* import cloudstorage as gcs def open_file(path, mode, **kwargs): f = gcs.open(path, mode=mode, **kwargs) if not f: raise Exception(File could not be opened: %s % path) return f -- We need a method of communicating with Cloud Storage that bypasses the URLFetch quotas and rate limits, or it becomes impossible for us to effectively execute parallel processing. *Is there a method of reading GCS files from App Engine that does not route through URLFetch*, much like the datastore API does not incur url fetch rate limits? I've detailed this question on Stackoverflow as well: http://stackoverflow.com/questions/31707961/urlfetch-rate-limits-with-google-cloud-storage -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/ffbec1ff-ed10-490d-b908-797bc6364398%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]
This issue was so hard to find, and related to the outgoing request, I believe a test-case would have been hard-pressed to find it. That said, the bug is on the stub implementation of the urlfetch API - I'd expect some request header tests as well. *shrug* can't catch 'em all On Tuesday, July 7, 2015 at 12:56:24 PM UTC-7, Karl MacMillan wrote: I got a confirmation this morning from support of this issue and a suggestion that it will be fixed in a subsequent release. Can I just ask some Googlers - how on earth did this issue slip by? This is the second serious SDK issue I’ve seen in recent months that would have been caught by the most obvious test in the world (the other was cloud storage being largely broken in the SDK). I don’t want to hammer too much, but seriously, do you not have tests at all for parts of the SDK? This is not a corner case - this is the most basic functionality being broken. I find it very, very concerning that your QA procedures are not catching such obvious bugs. Karl On Jul 7, 2015, at 2:12 PM, Aaron Madison aaron@imtapps.com javascript: wrote: Looks like a bug was filed yesterday. I'll update the SO post to reference this bug so hopefully more people can star it. https://code.google.com/p/googleappengine/issues/detail?id=12123 On Monday, July 6, 2015 at 9:24:54 PM UTC-5, Karl MacMillan wrote: I’ve seen this as well and submitted a support ticket. I did not find the debugging hilarious, but it’s nice to see someone else handle things with better humor than me. Karl On Jul 6, 2015, at 10:09 PM, Josh Whelchel (Loudr) jo...@loudr.fm wrote: There is an active issue with urlfetch_stub.py in the SDK where the FULL URL is being sent to the HTTP server as the path. Question and patch posted here: http://stackoverflow.com/questions/31195459/appengine-dev-appserver-urllib2-urlopen-issue-with-localhost-url Basically, it's connecting like this: Oh hey, http://localhost, we're connected, HI! Now that we're connected, can you give me URI http://localhost; Wait what, that's not right?? ooh. We found this while working on our elasticsearch integration, which was hilarious to debug. Imagine trying to find out why you have a new index named http: -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/5fbf8b6b-5fb4-4b1e-9a73-30d0a6a61661%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] URLFetch API Stub broken in GCloud SDK [with patch]
There is an active issue with urlfetch_stub.py in the SDK where the FULL URL is being sent to the HTTP server as the path. Question and patch posted here: http://stackoverflow.com/questions/31195459/appengine-dev-appserver-urllib2-urlopen-issue-with-localhost-url Basically, it's connecting like this: Oh hey, http://localhost, we're connected, HI! Now that we're connected, can you give me URI http://localhost; Wait what, that's not right?? ooh. We found this while working on our elasticsearch integration, which was hilarious to debug. Imagine trying to find out why you have a new index named http: -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/74688f8c-27f1-42fa-a706-ee83dc5de299%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Distributed Promises library for python on appengine
Oh man! This is like Pipelines Lite! I love it :D Some early feedback on the Count example - It seems odd to start your promises in the constructor, technically before you know that 'put' has completed. It's possible that the tasks trigger before the entity is saved. [now obviously, this may have been intended, because your just saving a count result - it's meant to count large numbers of entities, but what if that count is 0 ;D] This is a case where I'd leverage transactional task saves with the entity put. :) [but I don't know enough about the underlying architecture to know whether or not you require task names] Anyway, exciting! ps your article didn't mention pipelines, which are an incredibly useful asset: https://github.com/GoogleCloudPlatform/appengine-pipelines On Thursday, November 20, 2014 7:43:49 PM UTC-8, Emlyn wrote: Hi AppEngine Pythonistas, I've written a useful library for distributed processing in AppEngine, implementing distributed promises. They're described in detail in this post: https://point7.wordpress.com/2014/11/21/distributed-promises-for-appengine/ I want to open source the library, can anyone help me with best practices for creating an open source python package, including how to make that most easily accessible to appengine developers? -- Emlyn http://point7.wordpress.com - My blog https://plus.google.com/u/0/100281903174934656260 - Google+ -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: One senses GAE is just not a major priority for Google
Our experience couldn't be further from the opposite of what's being described in this thread. Google has been incredibly supportive of us as Appengine clients, and we've worked closely with their teams on feedback for the platform and the new console. Further, they've been taking a lot of their efforts to the open source community, including the pipeline and mapreduce libraries they have internally developed. [see https://github.com/GoogleCloudPlatform] Here's hoping your experiences improve! Also, to those criticisms of the new log viewer, what's the basis for your complaints? I love the new viewer and after adjusting to it (admittedly the transition took a few days) - it's MUCH faster and easier to use. Also, Cloud Debugger and Cloud Trace will blow your minds (see the GCP recordings if you can) - in particular, the watchpoints 3 On Friday, November 7, 2014 8:17:35 PM UTC-8, Brandon Thomson wrote: Perhaps it is selfish on my part, but in some ways I am glad that GAE is not getting much attention. Fixing bugs in legacy code is not exciting work and a new generation of engineers at Google may be tempted to improve things that aren't broken instead of doing the hard work of maintaining the existing code. As an example of an unwanted improvement, I would point to the new logs viewer currently being advertised in the admin console. I don't like it at all and I hope we will be able to keep using the existing logs viewer. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] ndb.add_flow_exception has no effect
It is an ERROR. This has also been answered on Stack: http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F23275230%2Freducing-log-clutter-via-ndb-add-flow-exception-with-deferred-taskssa=Dsntz=1usg=AFQjCNElwORRgoFq99y54gCRuWhRIu3apQ On Monday, May 5, 2014 11:10:36 PM UTC-7, Vinny P wrote: On Thu, May 1, 2014 at 3:29 PM, Josh Whelchel (Loudr) jo...@loudr.fmjavascript: wrote: I am unable to remove certain exceptions from our logs via ndb.add_flow_exception. The code above does not prevent CompletedExpectedException from appearing in the logs. This is primarily a problem because the only way that I know to 'fail' a deferred task is to throw an exception. (I know that I can use a direct taskqueue implementation with self.error(500) for this, but I'd still like to understand the functionality of ndb.add_flow_exception). It is documented here: https://developers.google.com/appengine/docs/python/ndb/functions When you see this exception, what logging level does it appear at (WARNING, DEBUG, etc)? - -Vinny P Technology Media Advisor Chicago, IL App Engine Code Samples: http://www.learntogoogleit.com -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
[google-appengine] ndb.add_flow_exception has no effect
I am unable to remove certain exceptions from our logs via ndb.add_flow_exception. class CompletedExpectedException(Exception): This Exception is completely expected. We don't need to see it as errors in the logs, or GAE dashboard graphs. pass # The following code, when on the 'global' app level, does not have an effect. ndb.add_flow_exception(CompletedExpectedException) # The following code does not work, eitherclass WarmupHandler(webapp2.RequestHandler): /_ah/warmup or /_ah/start def get(self): ndb.add_flow_exception(CompletedExpectedException) def post(self): self.get() The code above does not prevent CompletedExpectedException from appearing in the logs. This is primarily a problem because the only way that I know to 'fail' a deferred task is to throw an exception. (I know that I can use a direct taskqueue implementation with self.error(500) for this, but I'd still like to understand the functionality of ndb.add_flow_exception). It is documented here: https://developers.google.com/appengine/docs/python/ndb/functions As a side note - I would think this function, as documented, should belong in a different API than the datastore. *shrug* Also asked on Stack Overflowhttp://stackoverflow.com/questions/23275230/reducing-log-clutter-via-ndb-add-flow-exception-with-deferred-tasks, if you would like that sweet, sweet reputation. :P -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: images api issues
We are also seeing semi-frequent TransformationError exceptions being raised with no message attributed to them. On Thursday, May 1, 2014 3:24:20 AM UTC-7, Rafael Sanches wrote: Anyone else having recurrent issues with the images API? I know Google doesn't guarantee any SLA for that API, but the error rates are just terrible. Can someone please let me know what's happening and when it's going to be fixed? -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
