[google-appengine] Re: The price of Google Channel API

[Nick (Cloud Platform Support)]

Hi F. L. Lee, 

I understand your question now. I've investigated the docs page in question 
and it appears that you're correct that there's no mention of the actual 
pricing. I believe this may be a case of the docs needing an update and 
we're working on getting it fixed already. 

There are many resources out there on the web such as stackoverflow which 
point to previous price-points, but those of course can't be relied-on. 

In the meantime, you can test your billing using the Developers Console and 
its Billing section, along with precisely performing a few small tests 
which create channels and send a given number of bytes over them, etc. Of 
course, you could also wait while the docs become updated.

I hope this helps asnwer your questions. 

Sincerely,

Nick

On Thursday, August 27, 2015 at 1:29:26 AM UTC-4, F.L Lee wrote:
>
> Hi Nick,
>
> Thanks for your prompt response.  
> Sorry for the confusion,actually I would like to know such cost 
>  information, like "$ 0.026 per GB per month" for "Code and static data 
> storage". I can't find such cost description for "channel api"
>  Let me describe my questions in detail.
> 1) Suppose "Channels Created" of my application is 10,000 within today, 
> then how much should I pay for it?
> 2) Support "Channel Hours Requested" of my application is 20,000 within 
> today,   then how much should I pay for it?
> 3) Support we have 1 million clients, and each client need maintain a 
> channel for 24 hours each day , then how much should I pay for single day?
>
> Not sure if I have clear my question. looking forward to your reply.
>
> best regards,
> Forest
>
>
> On Wednesday, August 26, 2015 at 4:58:00 PM UTC+8, F.L Lee wrote:
>>
>> hi Guys,
>>
>> I have a question about the price of google channel API.  from 
>> https://cloud.google.com/appengine/docs/quotas, it claims, for paid 
>> user, the daily limits of "Channel Create" and "Channel Hour Requested" are 
>> both "based on your budget". Refer to the attached for more details.
>> I can't find exactly how to charge for the exceeded Channel Creates and 
>> Channel Hour Requests. Could you please give me more details or forward my 
>> question to proper people if you're not the one? Thanks in advance.
>>
>> best regards
>> Forest
>>
>

-- 
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/6a5d7fe9-8f59-435d-8183-26aad5c7d478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Why are cloud endpoints so slow ?

[Nick (Cloud Platform Support)]

Hi Thomas,

As this thread is quite old, it might be worth starting a new one which 
addresses any specific performance concerns you've noticed, along with data 
to demonstrate it. As Dan had said almost a year ago, improvements were in 
the works, and it's not certain that the same advice applies today.

Best wishes,

Nick

On Tuesday, August 11, 2015 at 4:19:51 AM UTC-4, Thomas Wiradikusuma wrote:
>
> Hi guys, 
>
> Any news on this? It's almost a year since last discussion here and Google 
> Cloud Endpoints is still very slow. 
>
> Regarding suggestion to "hit the rpc 50x to warm it up", how do you know 
> "when"? I mean, "hit rpc from time to time, and when it's slow, hit it 50x" 
> doesn't sound like a good solution for me.
>
>

-- 
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/8ddf4f51-16ef-4d65-910a-8317f7c3a88f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Problems with SSL on a custom domain

[Jon Travers]

Sorry, in point 2 of my explanation above I should have said the 
"ClientHello" message, not "ServerHello".

On Tuesday, 1 September 2015 23:06:51 UTC+1, Jon Travers wrote:
>
> Hi Patrice
>
> I can confirm that our office broadband, where we've consistently seen 
> this problem, is indeed a Sky connection. Since I last posted, I've done 
> some further investigation using Wireshark to capture and decode the TSL 
> protocol traffic being sent by Safari, Chrome, and Curl. My conclusion was 
> that the connection failure is caused by a very specific combination of 
> factors:
>
>1. There is some specific property of the TLS client setup that must 
>be present. I'm unable to identify exactly what, but on my machine it 
> fails 
>with up-to-date versions of Safari and Chrome, and also with the built-in 
>OpenSSL (0.9.8zg), but not with the version of Curl that I have, nor with 
>an updated version of OpenSSL. I can see differences in the connection 
>parameters between these clients, but it's unclear which one is the cause.
>2. The Initial TLS "ServerHello" message is being modified in a 
>specific way by some IP routing node between my computer, and the endpoint 
>at ghs.googlehosted.com. Based on all the evidence, we believe this is 
>definitely happening inside our ISP, Sky Broadband, but the same issue 
>could also occur on other routes. Whether this is the result of a 
>configuration error at Sky, or the result of something they're doing 
>deliberately, and how widespread this problem is, is all unclear.
>3. The server at the destination of the SNI TLS connection, 
>ghs.googlehosted.com, has been configured in such a way that the 
>combination of 1 and 2 is regarded as a terminal error, and the connection 
>is immediately terminated with an 'Illegal parameter' error. Connecting to 
>another SNI SSL server (our own proxy) does not trigger the same error 
>response, but since I can't see the traffic as it arrives at the Google, 
>and I don't have access to any further debug information from the server, 
> I 
>can't determine whether the rejection is valid. Most likely it is, and our 
>own proxy works simply because it has a less strict security setup.
>
> Now with these conclusions established, the only feasible solution I could 
> see was to try running the connection via a dedicated virtual IP address 
> (which costs $39 per month), rather than using the (free) SNI setup. I 
> finally gave in, paid our $39, updated our DNS records, and it worked 
> perfectly, no more connection errors. It's not exactly clear why this 
> works, but I'm actually very happy with this as a solution (other than 
> having to pay), especially since even if Sky fixes their routing error, I 
> can still be confident that if the same problem crops up somewhere else on 
> the Internet we won't be affected.
>
> *Bottom line: I would strongly advise anybody reading this to regard the 
> Google Apps SNI SSL service as inherently unreliable. Pay the money and go 
> with a virtual IP if at all possible, because the last thing you want is 
> for some of your customers to be unable to access your app depending on 
> where they are. I also think this advice should be clearly given in the 
> Google documentation.*
>
> Now Patrice, if you still want to investigate the specific issue at Sky, 
> then I'm very happy to provide you with additional debug information, once 
> I get into the office tomorrow morning (it's 11pm here now and I'm at 
> home). Can you be more specific about what you want? When you talk about 
> tcpdump output, are you looking for a capture of the network packets? So my 
> Wireshark capture would also be OK?
>
> Cheers
> Jon
>
> On Tuesday, 1 September 2015 20:03:50 UTC+1, Patrice (Cloud Platform 
> Support) wrote:
>>
>> Hi Hugo,
>>
>> Exactly what I was expecting. Whoever reports these always seem to be on 
>> Sky, which could be the problem.
>>
>> I don't know if you'll be able to get this since it's your users and not 
>> you directly, but if you could get a tcpdump and a print screen of the page 
>> "chrome://net-internals*" *from your affected user, maybe we'll be able 
>> to figure something out.
>>
>> Once you get these, don't send them publicly to the group. You can use 
>> the arrow pointing down by the reply button and select "reply privately to 
>> author" on one of my messages. 
>>
>> Cheers!
>>
>> On Tuesday, September 1, 2015 at 2:58:41 PM UTC-4, Hugo Visser wrote:
>>>
>>> The latest report came from a user on Sky. He also mentioned that 
>>> sometimes it works, and sometimes it doesn't. I can't verify if that's true 
>>> though. I've asked both users to open a browser to my custom domain app 
>>> url. I've now resorted to updating the app and setting the endpoint to the 
>>> appspot domain, which is not what I'd want ideally, but I don't want to 
>>> lose any users over it either.
>>>
>>> The user that contacted me stated

[google-appengine] Re: Problems with SSL on a custom domain

[Jon Travers]

Hi Patrice

I can confirm that our office broadband, where we've consistently seen this 
problem, is indeed a Sky connection. Since I last posted, I've done some 
further investigation using Wireshark to capture and decode the TSL 
protocol traffic being sent by Safari, Chrome, and Curl. My conclusion was 
that the connection failure is caused by a very specific combination of 
factors:

   1. There is some specific property of the TLS client setup that must be 
   present. I'm unable to identify exactly what, but on my machine it fails 
   with up-to-date versions of Safari and Chrome, and also with the built-in 
   OpenSSL (0.9.8zg), but not with the version of Curl that I have, nor with 
   an updated version of OpenSSL. I can see differences in the connection 
   parameters between these clients, but it's unclear which one is the cause.
   2. The Initial TLS "ServerHello" message is being modified in a specific 
   way by some IP routing node between my computer, and the endpoint at 
   ghs.googlehosted.com. Based on all the evidence, we believe this is 
   definitely happening inside our ISP, Sky Broadband, but the same issue 
   could also occur on other routes. Whether this is the result of a 
   configuration error at Sky, or the result of something they're doing 
   deliberately, and how widespread this problem is, is all unclear.
   3. The server at the destination of the SNI TLS connection, 
   ghs.googlehosted.com, has been configured in such a way that the 
   combination of 1 and 2 is regarded as a terminal error, and the connection 
   is immediately terminated with an 'Illegal parameter' error. Connecting to 
   another SNI SSL server (our own proxy) does not trigger the same error 
   response, but since I can't see the traffic as it arrives at the Google, 
   and I don't have access to any further debug information from the server, I 
   can't determine whether the rejection is valid. Most likely it is, and our 
   own proxy works simply because it has a less strict security setup.

Now with these conclusions established, the only feasible solution I could 
see was to try running the connection via a dedicated virtual IP address 
(which costs $39 per month), rather than using the (free) SNI setup. I 
finally gave in, paid our $39, updated our DNS records, and it worked 
perfectly, no more connection errors. It's not exactly clear why this 
works, but I'm actually very happy with this as a solution (other than 
having to pay), especially since even if Sky fixes their routing error, I 
can still be confident that if the same problem crops up somewhere else on 
the Internet we won't be affected.

*Bottom line: I would strongly advise anybody reading this to regard the 
Google Apps SNI SSL service as inherently unreliable. Pay the money and go 
with a virtual IP if at all possible, because the last thing you want is 
for some of your customers to be unable to access your app depending on 
where they are. I also think this advice should be clearly given in the 
Google documentation.*

Now Patrice, if you still want to investigate the specific issue at Sky, 
then I'm very happy to provide you with additional debug information, once 
I get into the office tomorrow morning (it's 11pm here now and I'm at 
home). Can you be more specific about what you want? When you talk about 
tcpdump output, are you looking for a capture of the network packets? So my 
Wireshark capture would also be OK?

Cheers
Jon

On Tuesday, 1 September 2015 20:03:50 UTC+1, Patrice (Cloud Platform 
Support) wrote:
>
> Hi Hugo,
>
> Exactly what I was expecting. Whoever reports these always seem to be on 
> Sky, which could be the problem.
>
> I don't know if you'll be able to get this since it's your users and not 
> you directly, but if you could get a tcpdump and a print screen of the page 
> "chrome://net-internals*" *from your affected user, maybe we'll be able 
> to figure something out.
>
> Once you get these, don't send them publicly to the group. You can use the 
> arrow pointing down by the reply button and select "reply privately to 
> author" on one of my messages. 
>
> Cheers!
>
> On Tuesday, September 1, 2015 at 2:58:41 PM UTC-4, Hugo Visser wrote:
>>
>> The latest report came from a user on Sky. He also mentioned that 
>> sometimes it works, and sometimes it doesn't. I can't verify if that's true 
>> though. I've asked both users to open a browser to my custom domain app 
>> url. I've now resorted to updating the app and setting the endpoint to the 
>> appspot domain, which is not what I'd want ideally, but I don't want to 
>> lose any users over it either.
>>
>> The user that contacted me stated that it broke several weeks ago.
>>
>> Hugo
>>
>> On Tuesday, September 1, 2015 at 5:16:34 PM UTC+2, Patrice (Cloud 
>> Platform Support) wrote:
>>>
>>> Hi Hugo, 
>>>
>>> Continuing to look into this, I realized that a lot of people who have 
>>> similar issues are all using a precise ISP. Do you know the ISP that your 

[google-appengine] Re: Push notifications sender module eats money

[pdknsk]

Just use managed VMs with f1-micro instances at $4.49 per month.

-- 
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/1dea3e7c-d2bc-4031-8ea8-7c4dc16f01c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Out of space error when deploying VM

[Patrice (Cloud Platform Support)]

Hi again Matt,

Thank you for being so thorough and looking into all the separate steps 
like that.

At this point, I think this will require some backend investigation on our 
part to figure out where this is holding up.

Do you mind posting the most basic "helloworld" example (or something 
equally trivial), but with your Dockerfile to the Issue Tracker 
? This way, we'll 
have steps to reproduce and I'll have someone from the managedVM team look 
into more details into this.

Thank you in advance

On Friday, August 28, 2015 at 5:32:47 PM UTC-4, Matt Hanson wrote:
>
> Actually I don't think this will work as they are private images, and I 
> get an error that the base image isn't found.

-- 
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/54f25581-fc93-4773-861f-f12ea748c40d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Push notifications sender module eats money

[Kaan Soral]

To add to this story, I have another app that I pay $18/daily that handles 
users at 100k magnitude

So, mostly, only the base cost is a bit high, once you scale, things become 
much more acceptable

On Tuesday, September 1, 2015 at 10:28:04 PM UTC+3, Kaan Soral wrote:
>
> I pay $15 daily for no traffic #cloudlyfe
>
> For me the cost is to keep instances primed as otherwise the delay can 
> reach 30 seconds for the user, which causes the app to lose it's very first 
> users, so $15/daily it is (and some periodic tasks)
>
> $54/mo is very acceptable, I would suggest only triggering a task when a 
> push notification is needed (one task, it could poll a bit more to make 
> sure you don't connect to APNS simultaneously etc.)
>

-- 
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/e2b8ffa5-1e73-4a1c-88e7-c56abfb32591%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Push notifications sender module eats money

[Kaan Soral]

I pay $15 daily for no traffic #cloudlyfe

For me the cost is to keep instances primed as otherwise the delay can 
reach 30 seconds for the user, which causes the app to lose it's very first 
users, so $15/daily it is (and some periodic tasks)

$54/mo is very acceptable, I would suggest only triggering a task when a 
push notification is needed (one task, it could poll a bit more to make 
sure you don't connect to APNS simultaneously etc.)

-- 
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/8ae0934a-6de0-45ae-b6be-647d8e80ce7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: AppEngine Datastore Admin fails with 500. Server Error. without Errors in Log...

[Nick (Cloud Platform Support)]

Hey Ruslan,

Google Groups isn't really the best place to post such a thread, since this 
forum is meant for more general discussion of the platform rather than 
individual technical issues. I suggest posting a thread to the public issue 
tracker  in 
instances such as these where it doesn't appear to be caused by your own 
code/configuration, with something breaking compared to the documentation / 
expectation. 

Nonetheless, I'm glad to help out for now. It used to be possible to view 
the ah-builtin-python-bundle module (the module handling the Datastore 
backup) from the "Monitoring > Logs" view of the Developers Console, but 
this doesn't appear possible anymore. You can, however, still view these 
logs in the old console at appengine.google.com. Let me know if you can 
find the cause of the errors by inspecting the logs there.

Best wishes,

Nick

On Tuesday, September 1, 2015 at 10:25:04 AM UTC-4, Ruslan Ragimov wrote:
>
> Hello everybody!
>
> Need help! I cannot backup my database on app engine using datastore admin 
> because I get 500 "Server Error" by opening datastore admin. 
> Can anybody help me? 
>
> The url which I can see at the moment of 500 server error is:
>
>
> https://ah-builtin-python-bundle-dot-bitstars-armro.appspot.com/_ah/login_redir?claimid=https://www.google.com/accounts/o8/id&continue=https://ah-builtin-python-bundle-dot-bitstars-armro.appspot.com/_ah/datastore_admin%3Fapp_id%3Ds~bitstars-armro
>
> This app has a custom domain configured on www.holobuilder.com. But I 
> don't think that this is the problem. Because I already have other apps 
> with custom domains which are works with datastore admin without problems. 
> One thing is that I use a shiro authentication on www.holobuilder.com and 
> on other apps just build in google authentication. May it cause the 
> problem? 
>
> And why I can't see any errors in the log on app engine...?!
>
> I will be happy for any help!
>
> Cheers!
>

-- 
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/0c01bcd7-7226-487c-bf90-edb7b394c64f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Problems with SSL on a custom domain

[Patrice (Cloud Platform Support)]

Hi Hugo,

Exactly what I was expecting. Whoever reports these always seem to be on 
Sky, which could be the problem.

I don't know if you'll be able to get this since it's your users and not 
you directly, but if you could get a tcpdump and a print screen of the page 
"chrome://net-internals*" *from your affected user, maybe we'll be able to 
figure something out.

Once you get these, don't send them publicly to the group. You can use the 
arrow pointing down by the reply button and select "reply privately to 
author" on one of my messages. 

Cheers!

On Tuesday, September 1, 2015 at 2:58:41 PM UTC-4, Hugo Visser wrote:
>
> The latest report came from a user on Sky. He also mentioned that 
> sometimes it works, and sometimes it doesn't. I can't verify if that's true 
> though. I've asked both users to open a browser to my custom domain app 
> url. I've now resorted to updating the app and setting the endpoint to the 
> appspot domain, which is not what I'd want ideally, but I don't want to 
> lose any users over it either.
>
> The user that contacted me stated that it broke several weeks ago.
>
> Hugo
>
> On Tuesday, September 1, 2015 at 5:16:34 PM UTC+2, Patrice (Cloud Platform 
> Support) wrote:
>>
>> Hi Hugo, 
>>
>> Continuing to look into this, I realized that a lot of people who have 
>> similar issues are all using a precise ISP. Do you know the ISP that your 
>> users have?
>>
>> Cheers!
>>
>> On Saturday, August 29, 2015 at 2:37:01 PM UTC-4, Hugo Visser wrote:
>>>
>>> Like I mentioned previously, today I got another user from the UK 
>>> reporting a similar issue. For some reason the SNI SSL served version of my 
>>> app isn't reachable or working for them, but going to 
>>> https://myapp.appspot.com works. I don't see a huge drop in usage in 
>>> the app so I can't really tell what is causing it, just that those users 
>>> can't establish a SSL connection to my custom domain url from their devices.
>>>
>>> Hugo
>>>
>>> On Wednesday, August 26, 2015 at 9:09:52 PM UTC+2, Patrice (Cloud 
>>> Platform Support) wrote:

 Hi again Jon,

 I continued trying to find what is exactly happening here. So here goes 
 :

 Running this in San Francisco :

 openssl s_client -debug -msg -servername dashboard.geospock.com 
 -connect dashboard.geospock.com:443 -showcerts 

 works perfectly and consistently. So I think we can all see that SF 
 won't have issues connecting here.

 I then connected through an European location, and from there, trying 
 this also succeeds:

 openssl s_client -servername dashboard.geospock.com -connect 
 64.233.167.121:443 -showcerts 
 curl -k -I --resolve dashboard.geospock.com:443:64.233.167.121 
 https://dashboard.geospock.com/ 

 From your error and your message, I get you're using TLS 1.0, while I 
 am running with TLS 1.2. I started looking into the version of openSSL 
 we're both using, and while you're using the 0.98zg, I am on 1.0.1f. 

 I believe since 0.9.8j SNI support was part of OpenSSL, so you using 
 0.98zg should work fine, but as a test, do you mind trying to run the same 
 with 1.01 latest? I believe they are up to 1.0.1p. If I remember 
 correctly, 
 there was a backport patch implemented in 0.9.8j to let openSSL work with 
 SNI (https://en.wikipedia.org/wiki/Server_Name_Indication ).

 The basis of the issue we have here is that I'm incapable of 
 reproducing any of the behaviors you're experiencing, so it's hard to 
 investigate further. I'm definitely interested in continuing this, but 
 without a reliable way for me to replicate, it's impossible to send it up 
 the chain to get it looked at and possibly fixed. If you have a specific 
 test case that consistently fail, that I can then reproduce on my side as 
 consistently, I'll be able to get some traction on this. 

 Thanks

 On Wednesday, August 26, 2015 at 11:16:54 AM UTC-4, Jon Travers wrote:
>
> Here is some more detailed debugging information from the failing 
> openssl SSL negotiation. Perhaps this would give you a clue what's 
> actually 
> going on?:
>
> $ openssl s_client -debug -msg -servername dashboard.geospock.com 
> -connect dashboard.geospock.com:443 -showcerts
> CONNECTED(0003)
> write to 0x7f96b8d006a0 [0x7f96b9802000] (131 bytes => 131 (0x83))
>  - 16 03 01 00 7e 01 00 00-7a 03 01 55 dd d7 93 c7   
> ~...z..U
> 0010 - f0 b2 0d ee ea f4 1c 2b-ee 50 b6 ff 0f e6 8f 59   
> ...+.P.Y
> 0020 - 8b 81 9e 05 2f 17 84 e2-20 ed b7 00 00 2e 00 39   /... 
> ..9
> 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   
> .8.5...3.2./
> 0040 - 00 9a 00 99 00 96 00 05-00 04 00 15 00 12 00 09   
> 
> 0050 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 23   
> ...#
> 0060 - 00 00 00 1b 

[google-appengine] Re: Problems with SSL on a custom domain

[Hugo Visser]

The latest report came from a user on Sky. He also mentioned that sometimes 
it works, and sometimes it doesn't. I can't verify if that's true though. 
I've asked both users to open a browser to my custom domain app url. I've 
now resorted to updating the app and setting the endpoint to the appspot 
domain, which is not what I'd want ideally, but I don't want to lose any 
users over it either.

The user that contacted me stated that it broke several weeks ago.

Hugo

On Tuesday, September 1, 2015 at 5:16:34 PM UTC+2, Patrice (Cloud Platform 
Support) wrote:
>
> Hi Hugo, 
>
> Continuing to look into this, I realized that a lot of people who have 
> similar issues are all using a precise ISP. Do you know the ISP that your 
> users have?
>
> Cheers!
>
> On Saturday, August 29, 2015 at 2:37:01 PM UTC-4, Hugo Visser wrote:
>>
>> Like I mentioned previously, today I got another user from the UK 
>> reporting a similar issue. For some reason the SNI SSL served version of my 
>> app isn't reachable or working for them, but going to 
>> https://myapp.appspot.com works. I don't see a huge drop in usage in the 
>> app so I can't really tell what is causing it, just that those users can't 
>> establish a SSL connection to my custom domain url from their devices.
>>
>> Hugo
>>
>> On Wednesday, August 26, 2015 at 9:09:52 PM UTC+2, Patrice (Cloud 
>> Platform Support) wrote:
>>>
>>> Hi again Jon,
>>>
>>> I continued trying to find what is exactly happening here. So here goes :
>>>
>>> Running this in San Francisco :
>>>
>>> openssl s_client -debug -msg -servername dashboard.geospock.com 
>>> -connect dashboard.geospock.com:443 -showcerts 
>>>
>>> works perfectly and consistently. So I think we can all see that SF 
>>> won't have issues connecting here.
>>>
>>> I then connected through an European location, and from there, trying 
>>> this also succeeds:
>>>
>>> openssl s_client -servername dashboard.geospock.com -connect 
>>> 64.233.167.121:443 -showcerts 
>>> curl -k -I --resolve dashboard.geospock.com:443:64.233.167.121 
>>> https://dashboard.geospock.com/ 
>>>
>>> From your error and your message, I get you're using TLS 1.0, while I am 
>>> running with TLS 1.2. I started looking into the version of openSSL we're 
>>> both using, and while you're using the 0.98zg, I am on 1.0.1f. 
>>>
>>> I believe since 0.9.8j SNI support was part of OpenSSL, so you using 
>>> 0.98zg should work fine, but as a test, do you mind trying to run the same 
>>> with 1.01 latest? I believe they are up to 1.0.1p. If I remember correctly, 
>>> there was a backport patch implemented in 0.9.8j to let openSSL work with 
>>> SNI (https://en.wikipedia.org/wiki/Server_Name_Indication ).
>>>
>>> The basis of the issue we have here is that I'm incapable of reproducing 
>>> any of the behaviors you're experiencing, so it's hard to investigate 
>>> further. I'm definitely interested in continuing this, but without a 
>>> reliable way for me to replicate, it's impossible to send it up the chain 
>>> to get it looked at and possibly fixed. If you have a specific test case 
>>> that consistently fail, that I can then reproduce on my side as 
>>> consistently, I'll be able to get some traction on this. 
>>>
>>> Thanks
>>>
>>> On Wednesday, August 26, 2015 at 11:16:54 AM UTC-4, Jon Travers wrote:

 Here is some more detailed debugging information from the failing 
 openssl SSL negotiation. Perhaps this would give you a clue what's 
 actually 
 going on?:

 $ openssl s_client -debug -msg -servername dashboard.geospock.com 
 -connect dashboard.geospock.com:443 -showcerts
 CONNECTED(0003)
 write to 0x7f96b8d006a0 [0x7f96b9802000] (131 bytes => 131 (0x83))
  - 16 03 01 00 7e 01 00 00-7a 03 01 55 dd d7 93 c7   
 ~...z..U
 0010 - f0 b2 0d ee ea f4 1c 2b-ee 50 b6 ff 0f e6 8f 59   
 ...+.P.Y
 0020 - 8b 81 9e 05 2f 17 84 e2-20 ed b7 00 00 2e 00 39   /... 
 ..9
 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   
 .8.5...3.2./
 0040 - 00 9a 00 99 00 96 00 05-00 04 00 15 00 12 00 09   
 
 0050 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 23   
 ...#
 0060 - 00 00 00 1b 00 19 00 00-16 64 61 73 68 62 6f 61   
 .dashboa
 0070 - 72 64 2e 67 65 6f 73 70-6f 63 6b 2e 63 6f 6d 00   
 rd.geospock.com.
 0080 - 23#
 0083 - 
 >>> TLS 1.0 Handshake [length 007e], ClientHello
 01 00 00 7a 03 01 55 dd d7 93 c7 f0 b2 0d ee ea
 f4 1c 2b ee 50 b6 ff 0f e6 8f 59 8b 81 9e 05 2f
 17 84 e2 20 ed b7 00 00 2e 00 39 00 38 00 35 00
 16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00
 96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00
 08 00 06 00 03 00 ff 01 00 00 23 00 00 00 1b 00
 19 00 00 16 64 61 73 68 62 6f 61 72 64 2e 67 65
 6f 73 70 6f 63 6b 2e 63 6f 6d 00 23 00 00
 read from 0x7f96b8d0

Re: [google-appengine] My basic_scaling instance hours are way too high

['Alex Martelli' via Google App Engine]

On Mon, Aug 31, 2015 at 4:00 PM, Dimitri Adamou <
dimitri.ada...@formitize.com> wrote:

> What would help is if we could input our set ups (eg basic_scaling /
> automatic_scaling b/f 1/2/3/4 and have the minimum (no traffic) vs maximum
> (constant traffic so always up) price ranges
>
> so eg
>
> I'm running
>
> 3 B4's on basic_scaling
> 1 B2 on manual
> and front-end F4 scaling with 4 maximum front end (My current monthly is
> just hitting 1k)
>

Thanks for the suggestion! (And, for once, this feature request is
appropriate here, since the cloud pricing calculator does not have its own
issue tracker). I've forwarded it to the team that own the cloud pricing
calculator, and they will be looking into it.


Alex


>
>
> On Tuesday, September 1, 2015 at 3:27:02 AM UTC+10, Alex Martelli wrote:
>>
>> Thanks for clarifying, and, I agree, it would be great to clarify the doc
>> page (I'll be working with the docs team on how exactly to do that -- it's
>> far from obvious, since said page is already big and inevitably
>> complicated).
>>
>> Meanwhile, could you please accept my answer to your Q on serverfault?
>> This way the issue will show up as "answered" and be findable that way by
>> others who may understandably run into the same issue of unclear
>> communication that you did.
>>
>> Thanks,
>>
>> Alex
>>
>>
>> On Sun, Aug 30, 2015 at 5:38 PM, Chester Moy 
>> wrote:
>>
>>> Then I did misinterpret the docs. It seemed like pretty explicit
>>> language to me,
>>> but I was making some assumptions.
>>>
>>> Instance usage is billed by instance uptime, at a given hourly rate.
>>> …
>>> Instances are priced based on an hourly rate determined by the instance
>>> class.
>>> …
>>> Manual and basic scaling instances are billed at hourly rates based on
>>> uptime.
>>>
>>> I took this to mean that instance classes had differing $/hr rates but,
>>> what
>>> it actually meant was i_hr/hr. That’s essentially the same thing if one
>>> were
>>> already paying for the service. But for someone who’s in the free tier,
>>> the wording
>>> was a little confusing.
>>>
>>> Thanks for your clarification. The docs are only clear for people already
>>> familiar with cloud computing terminology.
>>> ​
>>>
>>> --
>>> 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-appengi...@googlegroups.com.
>>> To post to this group, send email to google-a...@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/9ee9447e-c7d3-4121-b17a-c1c1fb78c021%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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/8261ce10-afa6-4d12-8ab5-40a2ce814eaa%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAE46Be_FrH_46e%2Bgoi_EveLAC6cXy%2Byi7eX4TXGyLb8dbUxgNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Help in mapping my domain to google app engine I mistyped the registrar password

[Steve Lewis]

That is EXACTLY what happened

On Tue, Sep 1, 2015 at 10:01 AM, pdknsk  wrote:

> I think the issue is as follows. He initially tried to use the automated
> setup, where you login to your registrar OAuth-style, and all the necessary
> changes are then made automatically. He mistyped the password, and was not
> offered this automated setup again, but had to go through the manual TXT
> process.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/CmB9utpH63U/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/750f10f5-cb89-452e-b410-f9c2d0bc67fe%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Steven M. Lewis PhD
4221 105th Ave NE
Kirkland, WA 98033
206-384-1340 (cell)
Skype lordjoe_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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CALEj8eO_EVcOMFZdimK4ERtoRJABSx4cYLnHv5jYi6JPOtqx9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Help in mapping my domain to google app engine I mistyped the registrar password

[pdknsk]

I think the issue is as follows. He initially tried to use the automated 
setup, where you login to your registrar OAuth-style, and all the necessary 
changes are then made automatically. He mistyped the password, and was not 
offered this automated setup again, but had to go through the manual TXT 
process.

-- 
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/750f10f5-cb89-452e-b410-f9c2d0bc67fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Backend instances are not deployed

[Tolga Tanrıverdi]

Hi Patrice

Thanks for the reply.
I've tried to specify my backend as dynamic and also resident. In both case 
the situation didn't change somehow app engine decide by itself for when to 
start my backends.

I'm starting my backends with connecting my backend servlet to  /_ah/start 
web service as much as I read from documentation it says /_ah/start starts 
when the instance is started.
And my backend servlet code is google's standard push notification code 
which you may find it in here:

https://github.com/GoogleCloudPlatform/solutions-ios-push-notification-sample-backend-java/blob/master/src/com/google/cloud/solutions/mobilepushnotification/PushNotificationWorkerServlet.java

Anyway I may change my backends to module but I don't know how. I'm using 
google eclipse plugin and I've created my project as google-> java web 
application
And as much as I can see java web application doesn't have support for 
ear(enterprise application) so is there any documentation to how to convert 
my java web application to enterprise application? And is it going to solve 
my problem ?

All I can see was the below documentation and it doesn't give the 
information that I need:
https://cloud.google.com/appengine/docs/java/modules/converting

Thanks
Tolga

1 Eylül 2015 Salı 19:16:57 UTC+3 tarihinde Patrice (Cloud Platform Support) 
yazdı:
>
> Hi,
>
> Looking into the java Backend documentation 
> ,
>  
> this seems to be expected. If you don't specify your instance to be 
> dynamic, it is "resident", which means it needs to be manually started.
>
> You should not use backends anymore, but modules. I would suggest using a 
> Manually scaled module. 
>
> In any case, in your specific case, what is getting called to start your 
> worker? Do you do the call yourself, is it part of your application?
>
> Cheers
>
>
>
> On Monday, August 31, 2015 at 7:06:57 PM UTC-4, Tolga Tanrıverdi wrote:
>>
>> I'm using google app engine for my IOS and Android application's server 
>> needs(Storing contents and datas for my applications) And I'm also using 
>> app engine to send push notifications to mobile clients. I'm using the 
>> below library to send push notifications:
>> https://github.com/GoogleCloudPlatform/solutions-ios-push-notification-sample-backend-java
>>
>> But when I integrate the above library to my code and deploy it to my 
>> google app engine account.GAE shows that there are backends in the code but 
>> it doesn't deploy it to any instances. [image: GAE Frontend & Backend 
>> Instance Deployments] 
>>
>> But after sometimes (after 2-3 hours) it automatically deploys the worker 
>> backend to 1 instance and then it starts to work and deliver 
>> notifications.But this is unaccaptable for me
>>
>> So what I want is,my worker backend to start working immediately with the 
>> frontend instance and shutdown immediately with the frontend.(So it 
>> shouldn't work 7/24 ) Do you know why it may happen? Am I missing something.
>>
>> You can find my app engine xml files below: *AppEngine-Web XML:*
>>
>> 
>> http://appengine.google.com/ns/1.0";>
>> tokyo-analyst-845
>> 1
>>
>> true
>>
>> true
>>
>> 
>> > value="WEB-INF/logging.properties"/>
>> 
>>
>> true
>>
>> 
>>
>> *Backends.XML:*
>>
>> 
>>   
>>   
>>
>> *Queue.XML:*
>>
>> 
>>   
>> notification-preprocessing
>> 200/s
>> 100
>>   
>>   
>> notification-delivery
>> pull
>>   
>>   
>> notification-device-token-cleanup
>> 10/s
>> 20
>> default
>>   
>> 
>>
>> *Web.XML:*
>>
>>   
>>  spring
>>  /
>>   
>>   
>>  contextConfigLocation
>>  
>> /WEB-INF/spring-servlet.xml
>>  
>>   
>>   
>>  
>> org.springframework.web.context.ContextLoaderListener
>>  
>>   
>> 
>>   PushNotificationWorkerServlet
>>   
>> com.finarapp.pn.controller.PushNotificationWorkerServlet
>> 
>> 
>>   PushNotificationWorkerServlet
>>   /_ah/start
>> 
>>
>> 
>>   PushPreProcessingServlet
>>   
>> com.finarapp.pn.controller.PushPreProcessingServlet
>> 
>> 
>>   PushPreProcessingServlet
>>   /admin/push/preprocessing
>> 
>>
>> Thanks
>>
>

-- 
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/4d7a4100-614e-46f4-bd3e-cab8cd8e44ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Backend instances are not deployed

[Patrice (Cloud Platform Support)]

Hi,

Looking into the java Backend documentation 
, 
this seems to be expected. If you don't specify your instance to be 
dynamic, it is "resident", which means it needs to be manually started.

You should not use backends anymore, but modules. I would suggest using a 
Manually scaled module. 

In any case, in your specific case, what is getting called to start your 
worker? Do you do the call yourself, is it part of your application?

Cheers



On Monday, August 31, 2015 at 7:06:57 PM UTC-4, Tolga Tanrıverdi wrote:
>
> I'm using google app engine for my IOS and Android application's server 
> needs(Storing contents and datas for my applications) And I'm also using 
> app engine to send push notifications to mobile clients. I'm using the 
> below library to send push notifications:
> https://github.com/GoogleCloudPlatform/solutions-ios-push-notification-sample-backend-java
>
> But when I integrate the above library to my code and deploy it to my 
> google app engine account.GAE shows that there are backends in the code but 
> it doesn't deploy it to any instances. [image: GAE Frontend & Backend 
> Instance Deployments] 
>
> But after sometimes (after 2-3 hours) it automatically deploys the worker 
> backend to 1 instance and then it starts to work and deliver 
> notifications.But this is unaccaptable for me
>
> So what I want is,my worker backend to start working immediately with the 
> frontend instance and shutdown immediately with the frontend.(So it 
> shouldn't work 7/24 ) Do you know why it may happen? Am I missing something.
>
> You can find my app engine xml files below: *AppEngine-Web XML:*
>
> 
> http://appengine.google.com/ns/1.0";>
> tokyo-analyst-845
> 1
>
> true
>
> true
>
> 
>  value="WEB-INF/logging.properties"/>
> 
>
> true
>
> 
>
> *Backends.XML:*
>
> 
>   
>   
>
> *Queue.XML:*
>
> 
>   
> notification-preprocessing
> 200/s
> 100
>   
>   
> notification-delivery
> pull
>   
>   
> notification-device-token-cleanup
> 10/s
> 20
> default
>   
> 
>
> *Web.XML:*
>
>   
>  spring
>  /
>   
>   
>  contextConfigLocation
>  
> /WEB-INF/spring-servlet.xml
>  
>   
>   
>  
> org.springframework.web.context.ContextLoaderListener
>  
>   
> 
>   PushNotificationWorkerServlet
>   
> com.finarapp.pn.controller.PushNotificationWorkerServlet
> 
> 
>   PushNotificationWorkerServlet
>   /_ah/start
> 
>
> 
>   PushPreProcessingServlet
>   
> com.finarapp.pn.controller.PushPreProcessingServlet
> 
> 
>   PushPreProcessingServlet
>   /admin/push/preprocessing
> 
>
> Thanks
>

-- 
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/8d48e8f0-cc1f-4b35-a3f9-a9570a4bc56c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Problems with SSL on a custom domain

[Patrice (Cloud Platform Support)]

Hi Hugo, 

Continuing to look into this, I realized that a lot of people who have 
similar issues are all using a precise ISP. Do you know the ISP that your 
users have?

Cheers!

On Saturday, August 29, 2015 at 2:37:01 PM UTC-4, Hugo Visser wrote:
>
> Like I mentioned previously, today I got another user from the UK 
> reporting a similar issue. For some reason the SNI SSL served version of my 
> app isn't reachable or working for them, but going to 
> https://myapp.appspot.com works. I don't see a huge drop in usage in the 
> app so I can't really tell what is causing it, just that those users can't 
> establish a SSL connection to my custom domain url from their devices.
>
> Hugo
>
> On Wednesday, August 26, 2015 at 9:09:52 PM UTC+2, Patrice (Cloud Platform 
> Support) wrote:
>>
>> Hi again Jon,
>>
>> I continued trying to find what is exactly happening here. So here goes :
>>
>> Running this in San Francisco :
>>
>> openssl s_client -debug -msg -servername dashboard.geospock.com -connect 
>> dashboard.geospock.com:443 -showcerts 
>>
>> works perfectly and consistently. So I think we can all see that SF won't 
>> have issues connecting here.
>>
>> I then connected through an European location, and from there, trying 
>> this also succeeds:
>>
>> openssl s_client -servername dashboard.geospock.com -connect 
>> 64.233.167.121:443 -showcerts 
>> curl -k -I --resolve dashboard.geospock.com:443:64.233.167.121 
>> https://dashboard.geospock.com/ 
>>
>> From your error and your message, I get you're using TLS 1.0, while I am 
>> running with TLS 1.2. I started looking into the version of openSSL we're 
>> both using, and while you're using the 0.98zg, I am on 1.0.1f. 
>>
>> I believe since 0.9.8j SNI support was part of OpenSSL, so you using 
>> 0.98zg should work fine, but as a test, do you mind trying to run the same 
>> with 1.01 latest? I believe they are up to 1.0.1p. If I remember correctly, 
>> there was a backport patch implemented in 0.9.8j to let openSSL work with 
>> SNI (https://en.wikipedia.org/wiki/Server_Name_Indication ).
>>
>> The basis of the issue we have here is that I'm incapable of reproducing 
>> any of the behaviors you're experiencing, so it's hard to investigate 
>> further. I'm definitely interested in continuing this, but without a 
>> reliable way for me to replicate, it's impossible to send it up the chain 
>> to get it looked at and possibly fixed. If you have a specific test case 
>> that consistently fail, that I can then reproduce on my side as 
>> consistently, I'll be able to get some traction on this. 
>>
>> Thanks
>>
>> On Wednesday, August 26, 2015 at 11:16:54 AM UTC-4, Jon Travers wrote:
>>>
>>> Here is some more detailed debugging information from the failing 
>>> openssl SSL negotiation. Perhaps this would give you a clue what's actually 
>>> going on?:
>>>
>>> $ openssl s_client -debug -msg -servername dashboard.geospock.com 
>>> -connect dashboard.geospock.com:443 -showcerts
>>> CONNECTED(0003)
>>> write to 0x7f96b8d006a0 [0x7f96b9802000] (131 bytes => 131 (0x83))
>>>  - 16 03 01 00 7e 01 00 00-7a 03 01 55 dd d7 93 c7   ~...z..U
>>> 0010 - f0 b2 0d ee ea f4 1c 2b-ee 50 b6 ff 0f e6 8f 59   ...+.P.Y
>>> 0020 - 8b 81 9e 05 2f 17 84 e2-20 ed b7 00 00 2e 00 39   /... ..9
>>> 0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   .8.5...3.2./
>>> 0040 - 00 9a 00 99 00 96 00 05-00 04 00 15 00 12 00 09   
>>> 0050 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 23   ...#
>>> 0060 - 00 00 00 1b 00 19 00 00-16 64 61 73 68 62 6f 61   .dashboa
>>> 0070 - 72 64 2e 67 65 6f 73 70-6f 63 6b 2e 63 6f 6d 00   rd.geospock.com
>>> .
>>> 0080 - 23#
>>> 0083 - 
>>> >>> TLS 1.0 Handshake [length 007e], ClientHello
>>> 01 00 00 7a 03 01 55 dd d7 93 c7 f0 b2 0d ee ea
>>> f4 1c 2b ee 50 b6 ff 0f e6 8f 59 8b 81 9e 05 2f
>>> 17 84 e2 20 ed b7 00 00 2e 00 39 00 38 00 35 00
>>> 16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00
>>> 96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00
>>> 08 00 06 00 03 00 ff 01 00 00 23 00 00 00 1b 00
>>> 19 00 00 16 64 61 73 68 62 6f 61 72 64 2e 67 65
>>> 6f 73 70 6f 63 6b 2e 63 6f 6d 00 23 00 00
>>> read from 0x7f96b8d006a0 [0x7f96b9807600] (7 bytes => 7 (0x7))
>>>  - 15 03 01 00 02 02 2f  ../
>>> <<< TLS 1.0 Alert [length 0002], fatal illegal_parameter
>>> 02 2f
>>> 8175:error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
>>> illegal 
>>> parameter:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_clnt.c:593:
>>>
>>

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

[google-appengine] AppEngine Datastore Admin fails with 500. Server Error. without Errors in Log...

[Ruslan Ragimov]

Hello everybody!

Need help! I cannot backup my database on app engine using datastore admin 
because I get 500 "Server Error" by opening datastore admin. 
Can anybody help me? 

The url which I can see at the moment of 500 server error is:

https://ah-builtin-python-bundle-dot-bitstars-armro.appspot.com/_ah/login_redir?claimid=https://www.google.com/accounts/o8/id&continue=https://ah-builtin-python-bundle-dot-bitstars-armro.appspot.com/_ah/datastore_admin%3Fapp_id%3Ds~bitstars-armro

This app has a custom domain configured on www.holobuilder.com. But I don't 
think that this is the problem. Because I already have other apps with 
custom domains which are works with datastore admin without problems. 
One thing is that I use a shiro authentication on www.holobuilder.com and 
on other apps just build in google authentication. May it cause the 
problem? 

And why I can't see any errors in the log on app engine...?!

I will be happy for any help!

Cheers!

-- 
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/e4ff50af-7142-4520-976f-85439185d53e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Unreliable fetching from BigQuery

[Patrice (Cloud Platform Support)]

Hi again Jeff,

So, looking back into the issue and your code, the only thing I can think 
of right now is that this may not be a BQ issue, but a URLfetch one. Are 
you sure your URLFetch has a proper timeout setup? This may not be simply 
because your timeout is too short, and sometimes the server takes a little 
bit longer than expected to respond, and that throws everything out.

I don't see in your samples how you setup your timeout for URLFetch. Has it 
been set elsewhere, or do you use the default one? The default being only 5 
seconds, its very possible this is your issue here.

Let me know if setting your deadline OR your default deadline helps :).

Cheers!

On Thursday, August 27, 2015 at 10:29:53 AM UTC-4, Patrice (Cloud Platform 
Support) wrote:
>
> Hey Jeff!
>
> At least you're not losing data because of this. 
>
> Normally you can do the same for your queries though. We always suggest to 
> code defensively, just in case there is an intermittent issue, or a network 
> issue, or maintenance on your instance, or any number of things. 
>
> I'm still trying to understand if what you're seeing is expected or higher 
> than the norm. As soon as I get anything I will let you know.
>
> Cheers
>
> On Wednesday, August 26, 2015 at 6:17:27 PM UTC-4, Jeff Schnitzer wrote:
>>
>> The inserts are all running from a task queue with the default backoff 
>> behavior, so I should be ok there. All the inserts seem to work on retry - 
>> I'm not losing data - I just get errors in my logs and a nastygram from 
>> Rollbar.
>>
>> Failing queries are a bigger issue because users see that.
>>
>> Thanks,
>> Jeff
>>
>> On Wed, Aug 26, 2015 at 8:25 AM, Patrice (Cloud Platform Support) <
>> pvoutsi...@google.com> wrote:
>>
>>> Hey Jeff,
>>>
>>> Thank you for that gist, it definitely contains everything we can 
>>> possibly be needing :).
>>>
>>> Just quickly looking at your "Insert All", I think there might be a way 
>>> to completely get out of the "URL not find" bind. I can't help but notice 
>>> you try the insert once, with no fallback. Is there some kind of 
>>> exponential backoff in another layer of your application? Because using an 
>>> exponential backoff to that insertAll (and probably to all the other calls 
>>> that sometimes throw similar errors) should take you out of this.
>>>
>>> I will still investigate to try and see what I can gather as to the root 
>>> cause of this. As soon as I find anything, I'll update the thread here.
>>>
>>> Cheers!
>>>
>>> On Tuesday, August 25, 2015 at 3:52:28 PM UTC-4, Jeff Schnitzer wrote:

 I put the query stacktrace and code in there, plus a few more 
 timestamps of occurrences that happened today/yesterday.

 Thanks,
 Jeff

 On Tue, Aug 25, 2015 at 12:21 PM, Jeff Schnitzer  
 wrote:

> gearlaunch-hub
>
> I'll add some more to the gist.
>
> Thanks,
> Jeff
>
> On Tue, Aug 25, 2015 at 11:11 AM, Ryan (Cloud Platform Support) <
> rbruy...@google.com> wrote:
>
>> More the better. What is your app id?
>>
>> On Tuesday, August 25, 2015 at 1:51:43 PM UTC-4, Jeff Schnitzer wrote:
>>>
>>> Thanks for looking into this. Here's a gist with some full 
>>> stacktraces and timestamps, plus the relevant code:
>>>
>>> https://gist.github.com/stickfigure/03149e24854936de1e1c
>>>
>>> One is a deferred task, one is a cron, but I also have failures with 
>>> normal user-facing query requests. I can dig some of those up too if it 
>>> helps.
>>>
>>> Thanks,
>>> Jeff
>>>
>>> On Tue, Aug 25, 2015 at 6:32 AM, Ryan (Cloud Platform Support) <
>>> rbruy...@google.com> wrote:
>>>
 Salutations Jeff,

 Can you send me the code you are using and full stack traces with 
 time stamps (more recent ones the better and multiple ones for 
 comparison).

 Thanks

 On Thursday, August 20, 2015 at 12:11:51 PM UTC-4, Jeff Schnitzer 
 wrote:

> I'm getting a lot of "Could not fetch URL" errors from BigQuery. 
> I'm not driving significant amounts of traffic to it (yet), but I get 
> one 
> of these maybe every 50 or so queries:
>
> Could not fetch URL: 
> https://www.googleapis.com/bigquery/v2/projects/gearlaunch-hub/queries
>
> I'm using the standard google-published bigquery client library 
> (Java). Any idea what is wrong? I don't have problems fetching from 
> any 
> other service.
>
> I'm ramping up traffic next week and this is going to start 
> happening a lot 
>
> Thanks,
> Jeff
>
 -- 
 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 googl

[google-appengine] Re: The API call urlfetch.Fetch() was explicitly cancelled

[Ryan (Cloud Platform Support)]

Salutations,

You will see this error when there is a async urlfetch call (could be 
warped in another call) that is not done when the page is finished loading. 
You need to make sure any async calls are completed before finishing your 
load.

On Monday, August 31, 2015 at 10:08:36 PM UTC-4, 한우람 wrote:
>
> I am using the Spring scheduler.
>
> GCS file was deleted by the scheduler is running.
>
> "The API call urlfetch.Fetch () was explicitly cancelled." error occurred.
>
> I want to know why.
>

-- 
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/022025a5-198b-4de1-8771-95a9f39a0361%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Push notifications sender module eats money

[André Solberg]

Hi, thanks for your reply.

Sorry, I pasted the wrong link, the tutorial I meant was this: 
https://cloud.google.com/solutions/mobile/ios-push-notifications/

I have done as described in this tutorial using the pull queue 
"notification-delivery" for sending notifications. So basically what I can 
do is just make this a push queue instead, set the module to automatic 
scaling, and then use the target parameter to that module when queueing the 
notifications, is that right?


On Tuesday, September 1, 2015 at 12:47:22 AM UTC+2, Nick (Cloud Platform 
Support) wrote:
>
> Hi Andre,
>
> So, there are several issues here, the most important to address to start 
> is the fact that as far as billing goes, you're responsible for anything 
> you deploy on the platform. Having a manual scaling module always up and 
> making requests constantly will definitely tend to increase your use of 
> billable resources.
>
> Now to get to the technical details, from reading the docs it's clear that 
> the push queue documentation doesn't recommend a manual scaling module in 
> this manner at all. The use of push queues is best combined with an 
> *automatic 
> scaling module*, so that the the tasks which are pushed will trigger 
> requests on that module, and it will spin up or down depending on the 
> volume of tasks to process. I think you're thinking of pull queues if 
> you've implemented something to check if queues are available. 
>
> As for your last question, you don't need to send push queue tasks to the 
> default module. You can set a module target when you create the task, and 
> this is described in the docs page you linked (ctrl + f "target").
>
> Let me know if I've misunderstood anything about your post or if you have 
> any questions beyond this and I'll be happy to help.
>
> Best wishes,
>
> Nick
>
> On Sunday, August 30, 2015 at 10:07:35 AM UTC-4, André Solberg wrote:
>>
>> I have an App Engine project as backend for an iOS app. The default 
>> module has dynamic scaling and is mostly idle. I have a separate module 
>> with manual scaling and 1 instance always running, which is constantly 
>> checking the task queue for notifications to send. After this module was 
>> deployed, instance hours exploded and I now have estimated charge of $54 
>> for this month. I basically followed the pattern that was described in this 
>> tutorial: 
>> https://cloud.google.com/appengine/docs/java/taskqueue/overview-push
>>
>> This pricing is unacceptable for a low traffic app like ours. Is my only 
>> other and cheaper option to just handle the sending of push notifications 
>> directly in the request to the default module, instead of enqueueing it in 
>> the task queue?
>>
>

-- 
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/fc745509-a3d3-4daa-9cbe-62f1c57ad874%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Naked and www custom domains with Google App Engine

[Richard Cheesmar]

Forgot to mention, the naked domain doesn't work on a phone under 3g either

On Tue, Sep 1, 2015 at 10:18 AM, Richard Cheesmar 
wrote:

> Excuse the typos1
>
> On Tue, Sep 1, 2015 at 10:16 AM, Richard Cheesmar 
> wrote:
>
>> Hi, Nick,
>>
>> Although, I cannot be positive without access to relevant servers, I'm
>> afraid it is a block. I think that your Public DNS servers along with
>> others like OpendDNS  are spoofed by Turk Telecom servers pretending to be
>> yours. Not only that, I think they have put in place IP blacklists on
>> certain blocks of IPs for Google and others, so it doesn't matter if you do
>> not use their DNS IPs. This has been going on sometime.
>>
>> I have used a Cname record for the www domain and that works just fine,
>> however, the naked domain is on a A name record and this originally had you
>> gae ip addresses in, 4 records in all. I then forwarded naked to www, but
>> it didn't work. I then deleted the A name records and replaced with a non
>> google ip address provided by whois.com. Still doesn't work inside
>> Turkey so I am thinking that maybe they have noted the naked domain and
>> prevent that, but maybe that is me beign paranoid. Either way it works fine
>> outside Turkey, just not inside.
>>
>> I have performed a traceroute for this and it hops 9 steps to a
>> turktelecom.com server in Ankara and then becomes anonymous. However, if
>> you run a traceroute from an online source it actually gets to the
>> destination. Pining simply return request timeouts here, however, the
>> whois.com support sent me screen shots of it pining successfully for
>> them.
>>
>> However, interestingly it won't ping from here:
>> http://tools.pingdom.com/ping/?target=emlakair.com&o=2&save=true , not
>> for me anyway, but you can see the forwarding working and perform a
>> traceroute.
>>
>> The www domain on the Cname record works fine and that is pointing to
>> ghs.googlehosted.com. In the beginning I had the naked domain working
>> within a Cname record also, but had to remove it as it was conflciting with
>> the MX records for the mail server who rely on the naked domain to serve me
>> mail. Cname record is taking priority so the MX records were not fired up.
>>
>> Anyway, I'm not sure what more I can do about this at the moment. I'm
>> still in Beta so will try to sort out before launching...properly
>>
>>
>> On Tue, Sep 1, 2015 at 1:51 AM, Nick (Cloud Platform Support) <
>> pay...@google.com> wrote:
>>
>>> Hi Richard,
>>>
>>> If you run a whois lookup on those addresses, you'll see they belong to
>>> Google. I'm not a lawyer and not an expert on international relations, but
>>> it's possible there is a block as you say. This might be caused from within
>>> your local network, a proxy or bridge used by an ISP, etc. Could you try to
>>> run a traceroute  or mtr
>>>  from your location to
>>> see exactly what happens to your packets?
>>>
>>> These are my first thoughts on debugging your connection problem.
>>>
>>> Best wishes,
>>>
>>> Nick
>>>
>>> On Sunday, August 30, 2015 at 6:06:46 AM UTC-4, Richard Cheesmar wrote:

 Ok, what is apparent is that the following set of ip addresses are
 being blocked in Turkey:

 216.239.36.21
 216.239.32.21
 216.239.38.21
 216.239.34.21

 Therefore, no naked custom domains with A records and these addresses
 are going to work in Turkey

 What is the solution: Signing Up to Google Apps and a work account so
 that I can redirect via the google admin console or do Google have another
 set of ip addresses for app engine projects that are not likely blocked?

 Anyone got any alternatives?


 On Saturday, August 29, 2015 at 10:01:54 AM UTC+3, Richard Cheesmar
 wrote:
>
> I have added two custom domains to Google Developers Console for a
> Google App Project.
>
>
> One, a naked domain with A and AAA records set on the third party DNS
> manager as specified by Google. Two, a www domain with a Cname record set
> on the third party DNS manager, as specified by Google.
>
>
> The www is serving, but the naked domain is not! The A records ip
> addresses timeout on my local machine but I get results when using
> http://tools.pingdom.com/ping/
>
> Obviously you can use more than one custom domain but is there
> something I'm missing here?
>
 --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Google App Engine" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-appengine/Me7Svp7kE88/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/gr

Re: [google-appengine] Re: Naked and www custom domains with Google App Engine

[Richard Cheesmar]

Excuse the typos1

On Tue, Sep 1, 2015 at 10:16 AM, Richard Cheesmar 
wrote:

> Hi, Nick,
>
> Although, I cannot be positive without access to relevant servers, I'm
> afraid it is a block. I think that your Public DNS servers along with
> others like OpendDNS  are spoofed by Turk Telecom servers pretending to be
> yours. Not only that, I think they have put in place IP blacklists on
> certain blocks of IPs for Google and others, so it doesn't matter if you do
> not use their DNS IPs. This has been going on sometime.
>
> I have used a Cname record for the www domain and that works just fine,
> however, the naked domain is on a A name record and this originally had you
> gae ip addresses in, 4 records in all. I then forwarded naked to www, but
> it didn't work. I then deleted the A name records and replaced with a non
> google ip address provided by whois.com. Still doesn't work inside Turkey
> so I am thinking that maybe they have noted the naked domain and prevent
> that, but maybe that is me beign paranoid. Either way it works fine outside
> Turkey, just not inside.
>
> I have performed a traceroute for this and it hops 9 steps to a
> turktelecom.com server in Ankara and then becomes anonymous. However, if
> you run a traceroute from an online source it actually gets to the
> destination. Pining simply return request timeouts here, however, the
> whois.com support sent me screen shots of it pining successfully for them.
>
> However, interestingly it won't ping from here:
> http://tools.pingdom.com/ping/?target=emlakair.com&o=2&save=true , not
> for me anyway, but you can see the forwarding working and perform a
> traceroute.
>
> The www domain on the Cname record works fine and that is pointing to
> ghs.googlehosted.com. In the beginning I had the naked domain working
> within a Cname record also, but had to remove it as it was conflciting with
> the MX records for the mail server who rely on the naked domain to serve me
> mail. Cname record is taking priority so the MX records were not fired up.
>
> Anyway, I'm not sure what more I can do about this at the moment. I'm
> still in Beta so will try to sort out before launching...properly
>
>
> On Tue, Sep 1, 2015 at 1:51 AM, Nick (Cloud Platform Support) <
> pay...@google.com> wrote:
>
>> Hi Richard,
>>
>> If you run a whois lookup on those addresses, you'll see they belong to
>> Google. I'm not a lawyer and not an expert on international relations, but
>> it's possible there is a block as you say. This might be caused from within
>> your local network, a proxy or bridge used by an ISP, etc. Could you try to
>> run a traceroute  or mtr
>>  from your location to see
>> exactly what happens to your packets?
>>
>> These are my first thoughts on debugging your connection problem.
>>
>> Best wishes,
>>
>> Nick
>>
>> On Sunday, August 30, 2015 at 6:06:46 AM UTC-4, Richard Cheesmar wrote:
>>>
>>> Ok, what is apparent is that the following set of ip addresses are being
>>> blocked in Turkey:
>>>
>>> 216.239.36.21
>>> 216.239.32.21
>>> 216.239.38.21
>>> 216.239.34.21
>>>
>>> Therefore, no naked custom domains with A records and these addresses
>>> are going to work in Turkey
>>>
>>> What is the solution: Signing Up to Google Apps and a work account so
>>> that I can redirect via the google admin console or do Google have another
>>> set of ip addresses for app engine projects that are not likely blocked?
>>>
>>> Anyone got any alternatives?
>>>
>>>
>>> On Saturday, August 29, 2015 at 10:01:54 AM UTC+3, Richard Cheesmar
>>> wrote:

 I have added two custom domains to Google Developers Console for a
 Google App Project.


 One, a naked domain with A and AAA records set on the third party DNS
 manager as specified by Google. Two, a www domain with a Cname record set
 on the third party DNS manager, as specified by Google.


 The www is serving, but the naked domain is not! The A records ip
 addresses timeout on my local machine but I get results when using
 http://tools.pingdom.com/ping/

 Obviously you can use more than one custom domain but is there
 something I'm missing here?

>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Google App Engine" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-appengine/Me7Svp7kE88/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/5b54d03d-cdf8-4056-a409-19f26b91f168%40googlegroups.com
>> 

Re: [google-appengine] Re: Naked and www custom domains with Google App Engine

[Richard Cheesmar]

Hi, Nick,

Although, I cannot be positive without access to relevant servers, I'm
afraid it is a block. I think that your Public DNS servers along with
others like OpendDNS  are spoofed by Turk Telecom servers pretending to be
yours. Not only that, I think they have put in place IP blacklists on
certain blocks of IPs for Google and others, so it doesn't matter if you do
not use their DNS IPs. This has been going on sometime.

I have used a Cname record for the www domain and that works just fine,
however, the naked domain is on a A name record and this originally had you
gae ip addresses in, 4 records in all. I then forwarded naked to www, but
it didn't work. I then deleted the A name records and replaced with a non
google ip address provided by whois.com. Still doesn't work inside Turkey
so I am thinking that maybe they have noted the naked domain and prevent
that, but maybe that is me beign paranoid. Either way it works fine outside
Turkey, just not inside.

I have performed a traceroute for this and it hops 9 steps to a
turktelecom.com server in Ankara and then becomes anonymous. However, if
you run a traceroute from an online source it actually gets to the
destination. Pining simply return request timeouts here, however, the
whois.com support sent me screen shots of it pining successfully for them.

However, interestingly it won't ping from here:
http://tools.pingdom.com/ping/?target=emlakair.com&o=2&save=true , not for
me anyway, but you can see the forwarding working and perform a traceroute.

The www domain on the Cname record works fine and that is pointing to
ghs.googlehosted.com. In the beginning I had the naked domain working
within a Cname record also, but had to remove it as it was conflciting with
the MX records for the mail server who rely on the naked domain to serve me
mail. Cname record is taking priority so the MX records were not fired up.

Anyway, I'm not sure what more I can do about this at the moment. I'm still
in Beta so will try to sort out before launching...properly


On Tue, Sep 1, 2015 at 1:51 AM, Nick (Cloud Platform Support) <
pay...@google.com> wrote:

> Hi Richard,
>
> If you run a whois lookup on those addresses, you'll see they belong to
> Google. I'm not a lawyer and not an expert on international relations, but
> it's possible there is a block as you say. This might be caused from within
> your local network, a proxy or bridge used by an ISP, etc. Could you try to
> run a traceroute  or mtr
>  from your location to see
> exactly what happens to your packets?
>
> These are my first thoughts on debugging your connection problem.
>
> Best wishes,
>
> Nick
>
> On Sunday, August 30, 2015 at 6:06:46 AM UTC-4, Richard Cheesmar wrote:
>>
>> Ok, what is apparent is that the following set of ip addresses are being
>> blocked in Turkey:
>>
>> 216.239.36.21
>> 216.239.32.21
>> 216.239.38.21
>> 216.239.34.21
>>
>> Therefore, no naked custom domains with A records and these addresses are
>> going to work in Turkey
>>
>> What is the solution: Signing Up to Google Apps and a work account so
>> that I can redirect via the google admin console or do Google have another
>> set of ip addresses for app engine projects that are not likely blocked?
>>
>> Anyone got any alternatives?
>>
>>
>> On Saturday, August 29, 2015 at 10:01:54 AM UTC+3, Richard Cheesmar wrote:
>>>
>>> I have added two custom domains to Google Developers Console for a
>>> Google App Project.
>>>
>>>
>>> One, a naked domain with A and AAA records set on the third party DNS
>>> manager as specified by Google. Two, a www domain with a Cname record set
>>> on the third party DNS manager, as specified by Google.
>>>
>>>
>>> The www is serving, but the naked domain is not! The A records ip
>>> addresses timeout on my local machine but I get results when using
>>> http://tools.pingdom.com/ping/
>>>
>>> Obviously you can use more than one custom domain but is there something
>>> I'm missing here?
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/Me7Svp7kE88/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/5b54d03d-cdf8-4056-a409-19f26b91f168%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Goog