[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-11-26 Thread Jonas Klemming
I am seeing the same issue. Did you resolve this? Den torsdag 12 oktober 2017 kl. 09:51:53 UTC+2 skrev Marco Galassi: > > Hi Jordan, thank you for your detailed response. > > Node.js is a single threaded runtime, this means that your code must be > properly >> coded to take full advantage of

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-10-12 Thread Marco Galassi
Hi Jordan, thank you for your detailed response. Node.js is a single threaded runtime, this means that your code must be properly > coded to take full advantage of Node.js's event loop > in > order to be asynchronous. >

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-10-11 Thread 'Jordan (Cloud Platform Support)' via Google App Engine
So just for completeness and clarity, the error you are seeing on your backend service "upstream prematurely closed connection while reading response header from upstream" strictly means that the nginx proxy on that specific instance of your backend service fails to contact the webserver (aka

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-10-10 Thread Marco Galassi
Hello Jordan, we are back because we have found the problem again. We have deleted the custom health check handler, disabled the health check in the *app.yaml* configuration file, but the problem is still there. Just to recap, what we keep seeing is the following. - From the proxy

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-10-02 Thread 'Jordan (Cloud Platform Support)' via Google App Engine
If properly responding to the health check with a message body *res.status(200).send('');* as the documentation states causes the health checks to fail, that would indeed warrant an issue to be reported in the PIT (public issue tracker). Note that responding to health checks is not required

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-10-02 Thread Marco Galassi
Hi Jordan, we would like to share with you what we have found. We have delete our custom health check that was an handler responding with 200 OK as follows: app.get('/_ah/health', function (req, res) { res.sendStatus(200); }); It looks like this has solved the problem as we *do not* see any

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-09-27 Thread 'Jordan (Cloud Platform Support)' via Google App Engine
If you have tested turning the nginx health checks off and you still see these 502 errors, then I highly suggest you report this in the Public Issue Tracker

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-09-27 Thread Marco Galassi
So, we took a step back in our project and deployed an Hello World application to see if the problem would still happen. We used the hello-world example in the Google App Engine code examples and edited it (our file is attached): there are no differences, but the fact that we don't have a

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-09-26 Thread 'Jordan (Cloud Platform Support)' via Google App Engine
You are very correct, as described in the previously linked Stack Exchange answer, nginx health checks are indeed the same health checks that are configurable via your

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-09-26 Thread Marco Galassi
Attaching a graphic description or current backend. On Monday, September 25, 2017 at 10:00:13 AM UTC+2, Marco Galassi wrote: > > We are performing a migration to a new backend hosted on Google App Engine > and based on Node.js. > > Before performing the switch from the old to the new backend,

[google-appengine] Re: Google App Engine, Nodejs, 502 Bad Gateway

2017-09-25 Thread 'Jordan (Cloud Platform Support)' via Google App Engine
You are very correct in your design pattern for testing a new backend. Duplicating live production requests and testing them against your new backend is actually the preferred way of testing before performing a migration. Having an App Engine proxy act like the actual client is also correct