On high traffic App Engine applications, you may occasionally see a request fail with error code 202. You’ll see the following text in your logs:
A problem was encountered with the process that handled this request, causing it to exit. This is likely to cause a new process to be used for the next request to your application. (Error code 202)
The request log will look similar to the picture below:
Error code 202 is an internal App Engine failure code: an unknown error occurred within App Engine or its associated services, not from your application. This is not an error that your application can catch or recover from, nor is the application at fault for this error. The current request will fail, but the client is free to retry the request. If this request is from the task queue service, the task queue will automatically retry the request if you set the appropriate settings while creating the task.
A note about error codes: the code 202 relates to App Engine; it is NOT a HTTP status code. When a request encounters this internal error, it fails with the HTTP status code 500 (as you can see from the above picture).
About a week ago, I saw this post https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/GdBqSxqviYk about instances being unable to load and failing initialization. I took one look at the picture provided, saw the line This request started at [time] and was still executing at [time, 1 minute later], and immediately assumed that the application’s init function was taking too long to run.
In most cases, that’s a fair assumption to make. One of the bigger pitfalls of App Engine is that instances have only 60 seconds to start up (load in all files and run the init method of servlets). It’s very common for developers to write in a huge amount of code within the init method, and then have instances fail startup because initialization took too long. In this case I believed init was the problem for one reason alone: the picture of the logging stack trace included references to ZIP I/O streams. Uncompressing and processing large ZIP files within the init function could easily take more than a minute.
However, it turned out that the developer wasn’t uncompressing ZIP files in the init – the answer was that App Engine was having a slow day, and was exceeding the 60 second startup limit just trying to uncompress the JAR. Which is pretty amazing and notable enough to comment on – the application didn’t even get fully extracted before App Engine shut down the instance as a failure.