Re: [google-appengine] Re: 502 bad gateway - flexible env - Strange behavior

1,187 views
Skip to first unread message

Deepak Singh

unread,
Jan 22, 2017, 2:05:19 PM1/22/17
to google-a...@googlegroups.com
My App was running for last six months on java flex env. Running fine. Last deployment was on 24/12/16 and it was working fine.
 Suddenly with new deployment, it now throws 502 for few calls which returns JSON via GET and POST. However there is no code change for that request.

More strange is that- Older version is working fine with same on flex env (vm:true) but new version with code throws 502(vm:true)...

Either you google guys provide a workaround or will move away from app engine.


Regards
Tech team


On Wed, Nov 23, 2016 at 11:28 PM, Jeff Payne <jeffk...@gmail.com> wrote:
I had this same problem using a memory intensive Flask based flex env app.  I finally investigated this locally at the system level and realized that a function, which I had not yet thought to optimize, was loading a huge file (500+ Gb) into memory.  I couldn't find anything in the logs to support this (I probably wasn't looking in the right logs), but I figured that the process/thread handling the request was choking behind the scenes.

My solution was:

1) Move the code that loaded the file into memory outside of the function so it was only loaded once, as the resulting object is thread safe.
2) Increase the memory of the VM used by the flex env. app using the resource settings explained here: https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml#resource-settings

Hope that helps!

On Monday, November 7, 2016 at 12:58:34 PM UTC-8, Suresh V wrote:


Any update on this? My instance, https://vplan-147418.appspot.com is doing this since last night.

Any tips to troubleshoot? This also uses the flexible environment,

--
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+unsubscribe@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/5d77111c-2770-4657-9fd1-5bcecc84efff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Deepak Singh

Attila-Mihaly Balazs

unread,
Feb 13, 2017, 9:06:11 AM2/13/17
to Google App Engine
AFAIK "vm: true" has been deprecated and you now need to use "env: flex".

Attila

Deepak Singh

unread,
Feb 13, 2017, 10:13:41 AM2/13/17
to google-a...@googlegroups.com
I went out of app engine and now running better with Amazon.
502/503 errors are not guaranteed and even gae team dont accept it until they reproduce it. 

On Mon, Feb 13, 2017 at 7:36 PM, Attila-Mihaly Balazs <dify...@gmail.com> wrote:
AFAIK "vm: true" has been deprecated and you now need to use "env: flex".

Attila

--
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+unsubscribe@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.

For more options, visit https://groups.google.com/d/optout.



--
Deepak Singh

Nicholas (Google Cloud Support)

unread,
Feb 13, 2017, 11:22:18 AM2/13/17
to Google App Engine
Hey Deepak,

My apologies as we seem to have missed this post.  Nevertheless, if you believe some behavior to be an error with the platform, the best place to report it for App Engine is the App Engine public issue tracker.  In doing so, you can submit screenshot, logs, reproductions, etc. with privacy so that we can help identify the root cause and improve the platform accordingly should the source prove to be platform-related.

In the issue report, please include the following:
  • Runtime used (runtime: custom, vm: true or env: flex).  These factors affect the serving infrastructure in the backend and knowing this greatly helps us narrow down a possible point of error.
  • Specific time frames.  Having specific timestamps of the first recorded occurrence and last recorded occurrence of a given error is very helpful.  Knowing this range can help us correlate your report with issues we might have filed internally accelerating our investigation.
  • SDK versions.  Knowing the code base can greatly trim down the research required to know where an error might be occurring if it is in fact with the platform.
  • Relevant logs.  502s are most often served by a nginx process in each VM instance that sits in front of your application container.  It has many uses including serving static resources according to handler rules defined in your app.yaml and serving 502s when the application container is unresponsive or otherwise crashes.  Good places to look for your logs:
    • Application logs. If your application encounters errors on specific lines of code, it may still be logging other statements effectively so this can help determine where in your handler code the error occurs
    • stdout, stderr.  If the runtime in the application container encounters errors, they may be found here.  Accessing locked down libraries for instance or attempting to write to a file-system withour write ability may generate errors visible here.
    • nginx.* logs.  If the application container is entirely unresponsive (which could happen if busy, crashed, out of memory, etc.), nginx should still get the requests and generate appropriate logs.  These log entries may indicate what the nginx process sent to the application container and what it received (or likely failed to receive)
    • Cloud HTTP Load Balancer request logs.  If the entire instance is unreponsive including its nginx process, the load balancer may respond with failure codes to ensure client requests don't hang forever.  This may happen if the application occupies all of the VM's resources like CPU or memory
I hope the above information is helpful to you and others in the community attempting to troubleshoot 502-3 errors.  After reporting a new issue on the tracker, feel free to post a link to it here so that others can follow through.

Regards,
Nicholas
Reply all
Reply to author
Forward
0 new messages