[google-appengine] Re: "Request was aborted after waiting too long to attempt to service your request." sprees

[Jason Collins]

More min_idle_instances (at an increased cost of course) will help service 
bursts and avoid these pending queue timeouts.


On Monday, 2 November 2015 18:05:30 UTC-8, Kaan Soral wrote:
>
> Yes, AppEngine can't handle bursts well, so the solution is to slow things 
> down
>
> Actually, there are speed limits on a lot of things that are usually not 
> advertised well, if you are getting these kind of errors, try to slow 
> things down and see how it goes
>
> Slowing things down is also pretty challenging, much harder than building 
> stuff that will scale
>
> On Monday, November 2, 2015 at 6:48:57 PM UTC+3, Alexandra wrote:
>>
>> Hi,
>>
>> Did you find the reason of these errors?
>>
>> I also see a lot of them. The time which is elapsed is about 10 min, so 
>> it seems that there are tasks that are stuck for some reason in the task 
>> queue.
>>
>> Any insights on that?
>>
>> Thanks
>> Alexandra
>>
>> On Saturday, April 11, 2015 at 8:02:34 PM UTC+3, Kaan Soral wrote:
>>>
>>> "Request was aborted after waiting too long to attempt to service your 
>>> request."
>>>
>>> I've been seeing these messages a lot lately, momentarily many requests 
>>> log these errors, it floods the error logs
>>>
>>> Anyone else?
>>>
>>

-- 
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/7b7bca79-e617-4660-bae3-dc0970c6c9e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: "Request was aborted after waiting too long to attempt to service your request." sprees

[Nick (Cloud Platform Support)]

@Kaan Soral

I think the issue cannot be adequately narrowed-down from the information 
provided, and with only the commonality of seeing the "Request was aborted 
after waiting too long to attempt to service your request." error, it's 
impossible to determine that the same issue is being reported by Alexandra 
- that's the reason why a proper issue report 
 is needed (see in 
that link a template).

There doesn't seem to be a basis for inferring the general statement that 
"AppEngine can't handle bursts well". This is especially so when the 
justification for the statement refers to a very specific use-case related 
to errors seen in a task queue with specific scaling settings. These 
scaling settings might be at the heart of the original issue reported at 
the top of the thread. Having a minimum and maximum of 1 idle instance 
doesn't exactly lend itself to managing every possible burst. 

Depending on the request pattern and start-up time, you could see strange 
scenarios where requests are building up in pending queues, instances are 
firing up and then shutting down after becoming idle, with the pending 
queues migrating and merging among these rapidly spawning and de-spawning 
instances. Requests in a rather short pending queue dealing with this 
potentially-volatile setup would not be seen to scale well, and many could 
in fact reach a timeout without getting to an instance. Again, this is a 
plausible explanation, but not confirmed by any real data. You can read in 
the docs some advice on how the scaling settings work 
, and how to best design 
for scaling events 
. Of course, as 
usual, if you have a specific issue, feel free to provide a report in the 
issue tracker .

On Monday, November 2, 2015 at 9:05:30 PM UTC-5, Kaan Soral wrote:
>
> Yes, AppEngine can't handle bursts well, so the solution is to slow things 
> down
>
> Actually, there are speed limits on a lot of things that are usually not 
> advertised well, if you are getting these kind of errors, try to slow 
> things down and see how it goes
>
> Slowing things down is also pretty challenging, much harder than building 
> stuff that will scale
>
> On Monday, November 2, 2015 at 6:48:57 PM UTC+3, Alexandra wrote:
>>
>> Hi,
>>
>> Did you find the reason of these errors?
>>
>> I also see a lot of them. The time which is elapsed is about 10 min, so 
>> it seems that there are tasks that are stuck for some reason in the task 
>> queue.
>>
>> Any insights on that?
>>
>> Thanks
>> Alexandra
>>
>> On Saturday, April 11, 2015 at 8:02:34 PM UTC+3, Kaan Soral wrote:
>>>
>>> "Request was aborted after waiting too long to attempt to service your 
>>> request."
>>>
>>> I've been seeing these messages a lot lately, momentarily many requests 
>>> log these errors, it floods the error logs
>>>
>>> Anyone else?
>>>
>>

-- 
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/a3d5858f-6d8b-4656-953a-2df06119c94c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: remote_api/oauth2 to connect to remote_api of a locally runing dev server instance?

[Jay]

How about just use of remote_api_shell.py as a python interpreter to the 
local dev app server? I do this all the time and it recently appears to 
have broken with the latest sdk. 
If I remote_api_shell -s localhost: I get 401. This worked until 
the last sdk update I think. If I remote_api_shell -s localhost: I 
don't get 401, I get in. However, in that case something is messed up with 
the context and if I do something with ndb transactions, for example, I get 
errors.

On Monday, November 2, 2015 at 11:56:37 AM UTC-6, Nick (Cloud Platform 
Support) wrote:
>
> To be as clear as possible, and since you might want to search this issue 
> and land on previous similar issues, I should mention there are threads out 
> there from past years where users had attempted and had limited success 
> using "localhost" or "127.0.0.1" (with / without port suffixes), although 
> given the age of such threads and the fact that such behaviour isn't 
> documented anywhere, I wouldn't put much trust in these things. Your 
> feature request could simply ask for a Development Server -oriented version 
> of  "ConfigureRemoteApiForOAuth" which already exists in the python SDK 
> for truly remote remote API use.
>
> On Monday, November 2, 2015 at 12:52:52 PM UTC-5, Nick (Cloud Platform 
> Support) wrote:
>>
>> You can connect to the Development Server's remote API in Java by following 
>> the pattern used in the docs 
>> 
>>  
>> (ctrl+f for "useDevelopmentServerCredential"). In the python docs 
>> , 
>> however, I don't see any such pattern. Checking into the source in the SDK 
>> of remote_api_stub.py, there doesn't seem to be any methods similar to 
>> useDevelopmentServerCredential() which would appear targeted at the 
>> Development Server. I think you should make a feature request in the public 
>> issue tracker  
>> for this.
>>
>> On Monday, November 2, 2015 at 12:58:23 AM UTC-5, A. Kong wrote:
>>>
>>> Hi,
>>>
>>> I have some client side scripts that use ClientLogin API to talk to 
>>> google app engine backend remote_api.
>>>
>>> I am switching to use oauth2 in these scrips to connect to the 
>>> remote_api of a google app engine instance. It is very straight forward so 
>>> far.
>>>
>>> However this does not allow the local client to connect to a locally 
>>> running dev server instance. It is because, first of all, dev_appserver.py 
>>> does not support https.
>>>
>>> So how can I connect to a locally dev instance's remote_api with oauth2? 
>>>
>>> Cheers, Tony
>>>
>>>

-- 
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/ffee5be6-6f0b-4b96-b77a-50faf69d5e64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Default namespace not working on production (multitenancy)

[Alejandro Casanovas]

I have an application that is working nice in the development server but 
when I upload it to appspot it stops working.


The problem as I see is that it's not recognizing the default namespace.


For example, the login stops working because Users are stored in the 
default namespace but I can not get them because the 'get' to the datastore 
returns 0 entities...


So... trying to get any entity from the default namespace does not work:


namespace_manager.set_namespace('')
users = User.query().fetch()


This returns 0 entities (but I have some stored!!)


If I try to get entites from another namespace it works:


namespace_manager.set_namespace('5644406578591168')
entities = Foo.query().fetch()


This returns the correct number of entites from the datastore


I can see all the entities and query them from the developer console.


Any help please?



-- 
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/7cf06276-7199-404c-a496-6c7e517ad085%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] How to store open connection to external MongoDB

[Minie Takalova]

Hello

I'am trying to build application on GAE which use MongoDB hosted at 
Mongolab provider.
Connection work, if I made new connection every request, but if I want to 
reuse once established connection, GAE freeze and die on timeout.
I believe that exist some simple way, how to do that such simple task.


-  This is woring, but open new connection every request: --
def get_database_connection():
client = pymongo.MongoClient(MONGO_URI)
DBCONN = client.get_default_database()
return DBCONN

DBCON = get_database_connection()
 ... do something usefull with DBCONN ...
 ... not store connection anywhere 
 ... end request 


 This freeze GAE and die on timeout ---
def get_database_connection():
if "DBCONN" in globals(): # look for open connection in 
instance memory
return globals()["DBCONN"]
client = pymongo.MongoClient(MONGO_URI)
DBCONN = client.get_default_database()
globals()["DBCONN"] = DBCONN  # store connection to instance memory
return DBCONN

DBCONN = get_database_connection()
 ... do something usefull with DBCONN ...
 ... end request  



Probably GAE module with backend thread can be uset to keep connection open 
in separate thread, but after many hours I can´t find working solution.
Hope somebody can experience with this usecase and can help me. Also link 
to well-tried solution will be helpfull. 

Have a nice day.




-- 
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/33df8ac3-d561-4726-8fbe-89bcaf14a9e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.