uncaught application failure - solved!

[Edwin Hoogerbeets]

I just spent the last day and a half banging my head against a wall trying to figure out what was wrong with my RingoJS app on Google App Engine. Finally, I figured it out, and I thought I should share it here so that I might save someone else some time and frustration, and perhaps even prevent some hair pulling and swearing.

I made a simple RingoJS app, got it working perfectly under the Google App Engine dev server. Then, I deployed it to Google App Engine, and went to the first URL. Nothing appeared in the browser window. But looking at the source of the page, it has HTML misinterpreted as text with a cryptic error message "s~myappid: Uncaught application failure" in it. Fine, so I went to the developer's console to look at the logs to find out what the mystery failure is. Nothing. All it says there is:

"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)"

No clues anywhere as to what that means. Searches on the net did not reveal anything other than that it may be an out-of-memory problem. I didn't think this could be possible for my relatively small new test app, so I tried putting in tonnes of log statements everywhere, but still to no avail. None of them were ever run. 

Then, I commented everything out in all js files, and things ran fine. It didn't do anything, but it ran at least without this uncaught failure problem. After probably 40 or 50 laborious deployments to GAE commenting in various parts of various files, none of which worked, I stumbled upon the idea that the failure happened while the js file was being loaded instead of while it was being run. I commented all the require() statements, and uncommented them one by one and finally found the culprit. A particular require() loaded in a library which in turn attempted to test whether a file outside of the web app's context was readable or not. This threw a java.security.AccessControlException which was caught and ignored nicely in the dev server. But, in the production GAE server, this exception caused the servlet's entire process to exit immediately and the above error to appear in the logs. There is no chance to catch the exception and do the appropriate thing because the handler exits before my own catch code can run. I don't know about you, but I think that a test for readability of a file should return a regular error code, not throw an uncatchable exception, as "permission denied" is not an abnormal result of such a test. It's why you do the test in the first place! The punishment is way out of line with the crime. Unfortunately, this library I was using can be used in node, browsers, or even in Qt/QML apps, where it is valid to test for the existence of those files in those contexts. I'll have to find another way to make sure it only attempts to test for files within the web app context when running under Ringo/GAE.

Summary:

1. You cannot test for the existence of files outside of the web app's context on GAE or else it will kill not just the request thread, but your entire app process. 

2. When you get Error Code 202 in your logs, it is possibly because something crashed while loading your servlet instead of while running it, and possibly it is a permission violation. Check your dev server logs carefully for any permission exceptions. This may give you clue.

I hope that saves someone some heartache. 

I need a beer now.

Edwin

[Philipp Naderer]

Hi Edwin!

I ran in a similar problem during the practical part of my master's thesis. My focus was on Java and App Engine, but I deployed a lot of Ringo code to test stuff and also just for fun.

App Engine's dev server allows some operations which will cause troubles in production. One has been the writes per second, which are too high in the dev environment. There exist some dev tuning parameters, but per default an application can write much faster in the dev server than in the production environment.

Another issue have been shutdown hooks. App Engine provides with the LifecycleManager API a way to detect instance shutdowns, but this needs App Engine specific code.

One time I had the same troubles with debugging a weird error code, which had no information about the cause. In my case the root cause was also a forbidden method call, but I don't remember the exact reason.

My overall experience is that Ringo integrates nice in App Engine, but from time to time minor adaptions to SDK changes are necessary. I like the fast development cycle compared to compiled Java. Saving a file, refresh the page and the dev server has all changes. On the other side it's a little bit harder to use Objectify as persistence layer. But since my data model changes only from time to time (and I had no bigger changes so far), it's easy to write the "DAO"s in good old Java and manipulate them in the Ringo application.

Bye,

Philipp

--
You received this message because you are subscribed to the Google Groups "RingoJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ringojs+u...@googlegroups.com.
To post to this group, send email to rin...@googlegroups.com.
Visit this group at http://groups.google.com/group/ringojs.
For more options, visit https://groups.google.com/d/optout.