[google-appengine] Re: Max size of entity.key.id() > uint64

[Jay Kyburz]

For the record, here is the docs on keys and ids

https://cloud.google.com/appengine/docs/python/ndb/creating-entity-keys#allocating_ids

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/34f48580-bdb8-4aef-bf72-084b9693243b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Max size of entity.key.id() > uint64

[Jay Kyburz]

Hey all, 

Today I'm integrating our app into the Steam store and I would like to use 
an entity's key.id() as an "orderid" which must be less than a uint64. 

Anybody know what the maximum number an entity's id can be when 
automatically generated?

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/066ffe0a-aa53-4fc8-ac25-eabadf4445ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: URL routing screwed up after deployment

[Mayank Bhagya]

Hello Nicholas,

Yes, there is a dispatch.yaml file in the code, but that is not present in 
the `gcloud preview app deploy' because there is no change in the routing 
rules.

As per dispatch.yaml, there is a rule:
 - url: "myapp.appspot.com/*"
   module: B

However, after a deployment, all requests of the form 
'myapp.appspot.com/hello/referrer', which usually go to B, started being 
redirected to A, which is the default module.
After 10 odd minutes, this gets auto fixed. This is extremely strange.

Also, that is the only rule that redirects to module B.

On Wednesday, 6 July 2016 01:47:33 UTC+5:30, Nicholas (Google Cloud 
Support) wrote:
>
> There are a few ways requests hitting the App Engine servers get routed to 
> your application's modules.  Namely, URL routing 
> 
>  
> and via dispatch rules 
> .  If 
> there is dispatch.yaml in your `gcloud app deploy` command, the rules 
> contained within will be applied before URL routing.
>
>- What dispatch rules do you have in your dispatch.yaml?
>- A request to what URL was incorrectly routed to your default module?
>- What specific rules are expected to route requests to module B?
>
>
> On Monday, July 4, 2016 at 1:54:13 PM UTC-4, Mayank Bhagya wrote:
>>
>> We have a jenkins push-to-deploy setup that uses gcloud to deploy an 
>> appengine application.
>>
>> After the deployment, suddenly all requests going to a module B start 
>> going to a module A (default module)!?
>>
>> How is that possible?
>> Why is the dispatcher screwed up after a 'gcloud preview app deploy'.
>> This has hurt many of our users today.
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/36c346b2-110b-495f-8a39-119aec8d3630%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: URL routing screwed up after deployment

['Nicholas (Google Cloud Support)' via Google App Engine]

There are a few ways requests hitting the App Engine servers get routed to 
your application's modules.  Namely, URL routing 

 
and via dispatch rules 
.  If 
there is dispatch.yaml in your `gcloud app deploy` command, the rules 
contained within will be applied before URL routing.

   - What dispatch rules do you have in your dispatch.yaml?
   - A request to what URL was incorrectly routed to your default module?
   - What specific rules are expected to route requests to module B?
   

On Monday, July 4, 2016 at 1:54:13 PM UTC-4, Mayank Bhagya wrote:
>
> We have a jenkins push-to-deploy setup that uses gcloud to deploy an 
> appengine application.
>
> After the deployment, suddenly all requests going to a module B start 
> going to a module A (default module)!?
>
> How is that possible?
> Why is the dispatcher screwed up after a 'gcloud preview app deploy'.
> This has hurt many of our users today.
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/91f27847-80b2-4f1a-9007-023d4135cfb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: images usage patterns

['Nick (Cloud Platform Support)' via Google App Engine]

Glad to hear you got it working, Frank! Best of luck in your future work.

On Monday, July 4, 2016 at 3:06:00 PM UTC-4, Frank Grossman wrote:
>
> Thank you Nick,
>
>I made a routine to refresh URLs. Looks like the stale one were all 
> from back in 2010. I will look at Cloud Storage for a future port. 
>
>  Frank
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/098ead06-59cf-4d31-b77c-4305082428e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Google Api key for localhost testing

[Richard Cheesmar]

Well, I can load the js without a key and it's working live, but somehow in 
development it's hit and miss. 

I am using places autocomplete which works fine sometimes but not others. 
Funny, exactly the same code on two different pages works differently, one 
will provide the autocomplete all the time, the other on 
occasions...Absolutely no difference in the autocomplete setup code. 
Debugged the heck out of it, but works fine now with a key so...

Although the referrers can be spoofed, the one that annoys is the 
localhost. I would have assumed that there would be some form of getting 
around the eating up the quota on that one.

I need to research a bit more I guess.

Thanks again for your input

Cheers

On Tuesday, July 5, 2016 at 7:21:25 PM UTC+3, Richard Cheesmar wrote:
>
> I have setup an api key for using amongst others the Google Maps Api, and 
> have setup referrers, including one for localhost on a specific port. 
>
> Two questions:
>
> 1. Does having a localhost referrer mean anyone can use the api key on 
> another their own development environment
> 2. Do localhost calls eat up your free allowance?
>
> 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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/7d564d64-5c4b-42c7-a1a2-74ead159a002%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: GAE Latency & Instance issues

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Folks,

As for the amount of concurrent requests an instance can handle, it depends 
on the CPU usage on the instance, and the number of concurrent requests the 
instance can handle is dependent on that, and the distribution of requests 
to instances is also dependent on statistical trends in latency. It's 
possible to see variable concurrent request performance dependent on how 
requests use up the resources for the given instance class 

 
and the latency statistics of requests on an instance.

I have one small recommendation relating to the mysterious gaps of time in 
requests. Using System.currentTimeMillis() 

 
calls (this is for java, but other runtimes have equivalent system calls) 
to surround calls to complex libraries, or any calls which require network 
activity, and you could be able to determine what exactly is taking up that 
time. It might be something optimize-able, or it might be a network issue. 
Depending on the nature of the network call itself, it could also be 
optimize-able.

Regards,

Nick
Cloud Platform Community Support

On Friday, July 1, 2016 at 3:28:51 AM UTC-4, Thomas Taschauer wrote:
>
> One thing I noticed is that the first request(s?) served by a fresh 
> instance will always be really slow. Not that they stay in the request 
> queue for a longer time (which is expected behaviour of course), but they 
> have long "pauses" in the middle of the request as you mentioned before, 
> usually up to 5 seconds in my case.
>
> What I'm going to test next is upgrading to F2 - hoping for smaller pauses 
> due to a faster CPU - and reverting other scaling-options to default (used 
> max_concurrent_requests and max_idle_instances before) hoping for the 
> AppEngine scaler to figure it out himself. :)
>
> On Thursday, June 30, 2016 at 1:13:42 PM UTC+2, troberti wrote:
>>
>> Great to hear that it helps. Actually, if you are using F4s, I might try 
>> a slightly higher max_concurrent_requests , say 4. Again, test and compare 
>> to be sure.
>>
>> Finally, to reduce costs, I would recommend to set max_idle_instances to 
>> 1. Keep min_idle_instances to what you need for your application. For us 
>> this reduces cost significantly without any apparent drawbacks.
>>
>> On Thursday, June 30, 2016 at 11:44:34 AM UTC+2, Trevor wrote:
>>>
>>> Well, I have to say thank you very, very much. Thanks to your advice we 
>>> have our lowest latency in 3 years! Sub 300ms average.  As expected though, 
>>> we are now sitting on 21 billed f4 instances, which will potentially cost 
>>> us in the order of 3x our current ($30-40 -> $100+), but we will tweak that 
>>> from tomorrow onwards. Peak hour is about to hit so we are going to see if 
>>> the system can keep sub-300ms at the current "automatic" setting for 
>>> scaling. But yes, once again, thank you for solving in 5 minutes what I 
>>> have been working on doing for 2 weeks (my tears are from joy and sadness 
>>> all at once)
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>
>>> On Thursday, June 30, 2016 at 6:03:23 PM UTC+9, troberti wrote:

 Right, you should definitely test and see what the results are. My 
 first inclination was also to increase max_concurrent_requests, but 
 because 
 then all those requests have increased latency, the actual QPS per 
 instance 
 decreased! Lowering max_concurrent_requests decreased request latency, so 
 each instance could process more requests/second.

 We use F1 instances, because we do not need the additional memory, and 
 our requests perform mostly RPCs. In our testing, faster instance classes 
 do process requests faster, but also cost significantly more.  F1s provide 
 the best performance/cost ratio for us. This could be a Python thing, not 
 sure. Again, you should really test and figure out what is the best for 
 your application+runtime.

>>>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/920f0f94-42fe-4237-aa51-9c17de2c736d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Google Api key for localhost testing

[Barry Hunter]

Hmm, yes, no signatures there. Even if did exist wouldnt really make sence.
If someone viewed the source to get the key, they could get the siganture
directly (the URL is no per request unique)

But you get 25,000 map loads per day. You would need a be doing a absolute
shedload of active development to burn though that.

The damage someone else can make to that quota is also limited. Would take
some very dedicated engineering to use much of it. Even some sort of
auto-refreshing page is likely to trigger other anti-abuse measures before
can make a dent.

The motivation to use your key is really low. As mentioned it bad as a DOS
vector, and keys are very easy to obtain. Can even get away with loading
the JS api without a key.



On 5 July 2016 at 18:58, Richard Cheesmar  wrote:

> Thanks Barry
>
> However, I'm using the google maps and places javascript api so don't
> think you can sign those right?
>
>
> On Tuesday, July 5, 2016 at 7:21:25 PM UTC+3, Richard Cheesmar wrote:
>>
>> I have setup an api key for using amongst others the Google Maps Api, and
>> have setup referrers, including one for localhost on a specific port.
>>
>> Two questions:
>>
>> 1. Does having a localhost referrer mean anyone can use the api key on
>> another their own development environment
>> 2. Do localhost calls eat up your free allowance?
>>
>> 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 https://groups.google.com/group/google-appengine.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/976af81a-6108-4a5f-a4f2-d9e52a37124e%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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAJCAUuK4agJmi%2B5B%2ByP_uoZPKtMjMk_6%2BnL6OjK%2BKMnB2kMQQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Google Api key for localhost testing

[Richard Cheesmar]

Thanks Barry

However, I'm using the google maps and places javascript api so don't think 
you can sign those right?


On Tuesday, July 5, 2016 at 7:21:25 PM UTC+3, Richard Cheesmar wrote:
>
> I have setup an api key for using amongst others the Google Maps Api, and 
> have setup referrers, including one for localhost on a specific port. 
>
> Two questions:
>
> 1. Does having a localhost referrer mean anyone can use the api key on 
> another their own development environment
> 2. Do localhost calls eat up your free allowance?
>
> 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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/976af81a-6108-4a5f-a4f2-d9e52a37124e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: /_ah/background stops executing with Firebase

['Nick (Cloud Platform Support)' via Google App Engine]

Just a quick update, it seems based on the above-linked repository, that 
there could be one explanation: 

if MessageProcessorServlet 

 creates 
an instance of MessagePurger 

 (extends 
Thread) and starts it, this thread will run forever unless interrupted, 
since it has a "while (true)" loop in its run() method. 
MessageProcessorServlet 

 should 
call interrupt() on the MessagePurger 

 during MessageProcessorServlet.destroy() 
.
 
If the servlet isn't destroyed, though, or is destroyed without a call to 
destroy(), the MessagePurger 

 thread 
might run long enough (as here) to be killed by the runtime. Or, given that 
in this case there doesn't appear to be any error text with the log line, 
perhaps these are simply long-running MessagePurger 

 threads 
which *were *properly destroyed, albeit after a long run.

I hope this is helpful, let me know your thoughts and any feedback on 
whether this is the library you're using.

Cheers,

Nick
Cloud Platform Support

On Tuesday, July 5, 2016 at 12:51:54 PM UTC-4, Nick (Cloud Platform 
Support) wrote:
>
> Hey Olof,
>
> Apologies for the slight delay. I'm still looking into any possible cause. 
> Could you share any of the information mentioned in my last message to help 
> speed this along? I'm looking at 
> https://github.com/GoogleCloudPlatform/firebase-appengine-backend right 
> now. Is this the library you're using?
>
> Sincerely,
>
> Nick
> Cloud Platform Community Support
>
> On Friday, July 1, 2016 at 5:00:20 AM UTC-4, Olof Gunnarsson wrote:
>>
>> I don't fully understand the logs, but it looks like it's older 
>> background threads. The timestamps in the screenshot are 5 hours apart.
>> The log messages "onAuthenticated" and "onDataChange" are Firebase 
>> callbacks. These log messages are not written after a couple of days, and 
>> they are also not executed (I delete stuff from Firebase in onDataChange, 
>> but the deletions stop after a couple of days)
>>
>> Attached is a better view of the log.
>>
>>
>>
>> On Friday, July 1, 2016 at 1:48:10 AM UTC+2, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Hey Olof,
>>>
>>> This is interesting. Could you clarify whether the logs are associated 
>>> with recent calls, or whether they are perhaps older background threads 
>>> which are closing due to their age? It appears the logs output got a bit 
>>> mangled as well during copy-paste, is there any chance a more faithful 
>>> reproduction of the complete logs info, or a screenshot with all fields 
>>> expanded, could be provided?
>>>
>>> Cheers,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Tuesday, June 28, 2016 at 5:24:02 AM UTC-4, Olof Gunnarsson wrote:


 I'm using Google Cloud Endpoints and Google App Engine with Firebase 
 (java). Firebase calls are done in a background thread "/_ah/background", 
 which works fine. However, after a couple of days the background thread 
 stops executing. Calls to GAE still work but calls to Firebase are not 
 executed. A restart of the instance makes everything work again.

 I get these in the log which contains log messages from my calls to 
 Firebase, and then suddenly I don't get anymore of these logs and the 
 calls 
 to Firebase stops executing.

 Any ideas?

 17:02:46.795GET0 B56,999.2 sUnknown/_ah/background
 17:02:46.795GET0 B34,555.2 sUnknown/_ah/background
 17:02:46.795GET0 B17,351 sUnknown/_ah/background
 17:02:46.795GET0 B17,350.9 sUnknown/_ah/background
 17:02:46.795GET0 B8,925.6 sUnknown/_ah/background
 17:02:46.795GET0 B8,923.4 sUnknown/_ah/background
 17:02:46.795GET0 B8,866 sUnknown/_ah/background
 17:02:46.795GET0 B8,131.1 sUnknown/_ah/background
 17:02:46.795GET0 B8,103.3 sUnknown/_ah/background
 17:02:46.795GET0 B8,101.8 sUnknown/_ah/background
 17:02:46.795GET0 B8,079.2 

[google-appengine] Re: /_ah/background stops executing with Firebase

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Olof,

Apologies for the slight delay. I'm still looking into any possible cause. 
Could you share any of the information mentioned in my last message to help 
speed this along? I'm looking at 
https://github.com/GoogleCloudPlatform/firebase-appengine-backend right 
now. Is this the library you're using?

Sincerely,

Nick
Cloud Platform Community Support

On Friday, July 1, 2016 at 5:00:20 AM UTC-4, Olof Gunnarsson wrote:
>
> I don't fully understand the logs, but it looks like it's older background 
> threads. The timestamps in the screenshot are 5 hours apart.
> The log messages "onAuthenticated" and "onDataChange" are Firebase 
> callbacks. These log messages are not written after a couple of days, and 
> they are also not executed (I delete stuff from Firebase in onDataChange, 
> but the deletions stop after a couple of days)
>
> Attached is a better view of the log.
>
>
>
> On Friday, July 1, 2016 at 1:48:10 AM UTC+2, Nick (Cloud Platform Support) 
> wrote:
>>
>> Hey Olof,
>>
>> This is interesting. Could you clarify whether the logs are associated 
>> with recent calls, or whether they are perhaps older background threads 
>> which are closing due to their age? It appears the logs output got a bit 
>> mangled as well during copy-paste, is there any chance a more faithful 
>> reproduction of the complete logs info, or a screenshot with all fields 
>> expanded, could be provided?
>>
>> Cheers,
>>
>> Nick
>> Cloud Platform Community Support
>>
>> On Tuesday, June 28, 2016 at 5:24:02 AM UTC-4, Olof Gunnarsson wrote:
>>>
>>>
>>> I'm using Google Cloud Endpoints and Google App Engine with Firebase 
>>> (java). Firebase calls are done in a background thread "/_ah/background", 
>>> which works fine. However, after a couple of days the background thread 
>>> stops executing. Calls to GAE still work but calls to Firebase are not 
>>> executed. A restart of the instance makes everything work again.
>>>
>>> I get these in the log which contains log messages from my calls to 
>>> Firebase, and then suddenly I don't get anymore of these logs and the calls 
>>> to Firebase stops executing.
>>>
>>> Any ideas?
>>>
>>> 17:02:46.795GET0 B56,999.2 sUnknown/_ah/background
>>> 17:02:46.795GET0 B34,555.2 sUnknown/_ah/background
>>> 17:02:46.795GET0 B17,351 sUnknown/_ah/background
>>> 17:02:46.795GET0 B17,350.9 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,925.6 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,923.4 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,866 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,131.1 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,103.3 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,101.8 sUnknown/_ah/background
>>> 17:02:46.795GET0 B8,079.2 sUnknown/_ah/background
>>>
>>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/5f2cb57e-8e31-4914-b5a4-282771a33d71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Google Api key for localhost testing

[Barry Hunter]

>
>


>> 1. Does having a localhost referrer mean anyone can use the api key on
>> another their own development environment
>>
>
Yes. And add a signature to make it harder for others to 'abuse' your key.



> 2. Do localhost calls eat up your free allowance?
>>
>
Yes. AFAIK


3. Is it an absolute to have an api key, if so how come my website is
> working without at this point in time?
>

It depends in part on the specific API. Some are more stringent than
others.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAJCAUuJL23XH5mPVLAPd32505m9LyaxNtfsnXFQwRD3gdwpCbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Google Api key for localhost testing

[Richard Cheesmar]

I have setup an api key for using amongst others the Google Maps Api, and 
have setup referrers, including one for localhost on a specific port. 

Two questions:

1. Does having a localhost referrer mean anyone can use the api key on 
another their own development environment
2. Do localhost calls eat up your free allowance?

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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a306791a-2bec-4a28-9e2e-b877c23da0b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Google Api key for localhost testing

[Richard Cheesmar]

Oh, just thought of a third

3. Is it an absolute to have an api key, if so how come my website is 
working without at this point in time?

On Tuesday, July 5, 2016 at 7:21:25 PM UTC+3, Richard Cheesmar wrote:
>
> I have setup an api key for using amongst others the Google Maps Api, and 
> have setup referrers, including one for localhost on a specific port. 
>
> Two questions:
>
> 1. Does having a localhost referrer mean anyone can use the api key on 
> another their own development environment
> 2. Do localhost calls eat up your free allowance?
>
> 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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/f3214293-119b-496c-8c4f-4abc32fb1515%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: New Datastore Pricing July 1st 2016

[Marcel Manz]

It appears that the 'Charges this month' page 
(https://console.cloud.google.com/billing/unbilledinvoice) has not yet been 
updated according the new pricing scheme.

This page still lists 'Datastore Write Ops' and an estimated $ amount. It 
should instead show the new billing ops like 'Datastore Entity Writes' and 
similar.

The dashboard as well as quota usage history are correctly showing the new 
charges for us. Strangly though that there is an inconsistency between 
'Datastore Stored Data' amount from Quota Details (smaller value, matching 
dashboard value) opposed to Quota History (larger value, according to which 
charging is done). In our case the difference between these 2 values is 
around 10%.

Can Google please comment why these values are not the same?

Regards
Marcel

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/f0cb929d-487d-4e15-bae3-ba55f5034092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Show and Tell: Geobird - A Location Based Platform Built with AppEngine

[Kaan Soral]

I feel your pain, yet don't agree completely, yes back in the day we had 
some hard times, but recently things have been pretty positive - at one 
occasion, reps even pledged to "move mountains" for us, if demand needs be

For me the challenges have been more throughput related, you can't just 
blast a service and expect it to handle that blast gracefully, each service 
seems to have it's own limits that are not always apparent

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/4125b256-b5a9-4e44-9cd5-806791256ef0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: How to use GAE SDK in GCE development Server

[Dhandapani Sattanathan]

Thanks Adam,

I added the following line to each user's startup script

export PATH="$PATH:/path/to/google_appengine/"

Using SSH connection i opened the terminal.
user@lamp-bafs:~$  mkdir gaedev



user@lamp-bafs:~$ cd gaedev

user@lamp-bafs:~$ wget -O gae.zip https:
//storage.googleapis.com/appengine-sdks/featured/google_appengine_1.9.38.zip

user@lamp-bafs:~$ unzip gae.zip


user@lamp-bafs:~$ echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/php

user@lamp-bafs:~$ export PATH="$PATH:/home/gaedev/google_appengine/"

user@lamp-bafs:~$ echo $PATH


user@lamp-bafs:~$ echo $PATH

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/bin/php:/home/
gaedev/google_appengine

user@lamp-bafs:~$ cp -r google_appengine/new_project_template testapp

user@lamp-bafs:~$python google_appengine/dev_appserver.py testapp

INFO 2016-06-22 05:00:00,836 sdk_update_checker.py:229] Checking for 
updates to the SDK.WARNING 2016-06-22 05:00:02,159 simple_search_stub.py:
1146] Could not read search indexes from /tmp/appengine.new-project-template
.user/search_indexesINFO 2016-06-22 05:00:02,170 api_server.py:205] Starting 
API server at: http://localhost:37210INFO 2016-06-22 05:00:02,177 
dispatcher.py:197] Starting module "default" running at: 
http://localhost:8080INFO 2016-06-22 05:00:02,179 admin_server.py:116] 
Starting admin server at: http://localhost:8000

After this I do not see the default browser opening. 

Could you plz help us how to use remote appengine SDK(installed in this GCE 
instance).All developers want to use one common SDk from this remote 
machine?
On Saturday, July 2, 2016 at 10:33:37 PM UTC+5:30, Adam (Cloud Platform 
Support) wrote:
>
> Assuming your remote GCE instance is Linux, you can just install the SDK 
> on the GCE instance as you would normally following the instructions for 
> 'installing 
> on Linux' 
> . 
> I usually install under /opt eg. /opt/google_appengine.
>
> To ensure the SDK is in each user's PATH, add the following line to each 
> user's startup script (eg. .bash_profile):
>
> export PATH="$PATH:/path/to/google_appengine/"
>
> On Friday, July 1, 2016 at 3:12:53 AM UTC-4, Dhandapani Sattanathan wrote:
>>
>> Hello,
>>
>>
>>1. 
>>
>>We are a team of 10 developers and want to develop PHP on GAE using 
>>the same SDK version from a remote server.
>>2. 
>>
>>So, we want to install the GAE PHP SDK on the remote GCE instance 
>>once.
>>3. 
>>
>>Subsequently, all developers will use that remote PHP SDK installed 
>>in that GCE instance.
>>
>> This is to avoid installing or working in different versions of GAE SDK 
>> in our individual local machines. We don't want to install in each of our 
>> local machines, whenever there is a new Release of GAE SDK. We just want to 
>> update once in GCE instances, with the new GAE SDK in one centralized 
>> place, to ensure all developers develop the code using the same version of 
>> GAE SDK. We also don't want to waste time to install SDK in each machine to 
>> ensure consistency in development environments.
>>
>> In this context, can you please enlighten us to centralize our GAE SDK in 
>> GCE development server
>>
>> Thanks very much in advance,
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/71cbcf45-7ea9-4899-8a5f-66613960774f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.