help on backends

842 views
Skip to first unread message

GAEfan

unread,
Apr 26, 2013, 12:08:20 PM4/26/13
to google-a...@googlegroups.com
Must be something simple I'm missing out of the docs...  I have set up a backend, but cannot access it.  I have the backend running (see screenshot), but if I click the link, or access it by <backend-name>.<app-name>.appspot.com (or with 0. prefix), it throws a 503:

Error: Server Error

The service you requested is not available yet.

Please try again in 30 seconds.

(BTW... When I first hit it, it gave a 500, like it was inaccessible.  On subsequent hts, it gives the 503)

backends.py:

backends:
- name: backend-name
  class: B2
  instances: 1
  options: dynamic, public

Since I see it as running in the dashboard, there is no need to start/stop it via appcfg, correct?

Nothing shows up in the logs, so not sure how to proceed to troubleshoot.

Thanks.
backends.png

Vinny P

unread,
Apr 26, 2013, 12:32:00 PM4/26/13
to google-a...@googlegroups.com
The first 500 error is likely the backend getting allocated and built by the GAE scheduler. The subsequent 503s indicate that there may be a problem with the backend application. 

Are you sure that there are no logs? Try going into the logs page, and using the dropdown box in the middle of the page. It has separate entries for frontend version log and backend version logs. Is the backend log entry selected?


-----------------
-Vinny P
Technology & Media Advisor
Chicago, IL

My Go side project: http://invalidmail.com/

GAEfan

unread,
Apr 26, 2013, 12:42:44 PM4/26/13
to google-a...@googlegroups.com
Thanks, Vinny.

I missed that logs menu.  There are logs.  The error is a 301 at  /_ah/start :

Process terminated because it failed to respond to the start request with an HTTP status code of 200-299 or 404.

So, do I have to add /_ah/start to app.yaml?  That should be handled automatically.
Also, re: the 500 error... Shouldn't the request wait until the backend instance is started?  Otherwise, we have to hit it twice?

Thanks again.
Enter code here...


Vinny P

unread,
Apr 26, 2013, 2:26:41 PM4/26/13
to google-a...@googlegroups.com

On Friday, April 26, 2013 11:42:44 AM UTC-5, GAEfan wrote:
Thanks, Vinny.

I missed that logs menu.  There are logs.  The error is a 301 at  /_ah/start :

Process terminated because it failed to respond to the start request with an HTTP status code of 200-299 or 404.
So, do I have to add /_ah/start to app.yaml?  That should be handled automatically.

It's already mapped.

So quick refresher on backend startup: When AppEngine starts up a backend, it calls the _ah/start url, That signals the scheduler to allocate and kick up a backend, and to run any initialization procedures that are required (so for example. in Java it runs the init() function). A 404 status code means that this backend has not defined any _ah/start methods, and that it doesn't need any initialization; it's ready to go from birth! A 2xx response means that the backend did define a startup function, and that function has been called, executed, and completed successfully, and now it may be used for traffic. 

But here's the problem: AppEngine called your _ah/start, and something went wrong, that's why it's complaining of a "failed to respond" properly. Now, we don't actually know what exactly went wrong; we just know that something, somewhere failed during instance startup. If I were you, I'd take a long hard look at the application's startup code: is it possible, even remotely, that any code in there can fail? Start pulling out code and testing it again, if you have to. 

After all that, if you cannot find any failures, file a ticket. I remember a time with a customer (a long time ago) where the backend was stuck for some reason - application code deployed and worked fine on other app IDs, it just refused to work on a particular app ID. Our executives called our Google rep, and apparently the problem was something got stuck in the scheduler (some reason like that, like I said, it was a long time ago, and there's a nonzero possibility that the executives just didn't care about what the reason was). 


On Friday, April 26, 2013 11:42:44 AM UTC-5, GAEfan wrote:
Also, re: the 500 error... Shouldn't the request wait until the backend instance is started?  Otherwise, we have to hit it twice?


Like I said above, the backend instance is not starting at all; it's failing somewhere at startup. Once you get that resolved, you only need to hit it once.

Also, for some reason, starting up a backend after a new deploy/config setting just takes more time than starting up a new frontend instance. My theory is that the scheduler takes longer to allocate backend instances because it tries to find a server that can maintain a long lasting instance; but that's just my pet theory, you'd have to ask Google's scheduler people what is actually going on.

GAEfan

unread,
Apr 26, 2013, 2:56:42 PM4/26/13
to google-a...@googlegroups.com
Thanks, Vinny.

So, no changes needed to app.yaml?  

Could it be a version issue?  Backends does not yet have versioning.  But, how does it know which version of my app to access?  It should just default to the current.

I have only one instance set up.

So, I am getting a 301 at  " /_ah/start".  I do have a wildcard url handler (- url: /.*).  WIthout a "/_ah/start" handler in app.yaml, is it hitting the wildcard mapping before the built-in mapping?

This should not be this difficult.

Vinny P

unread,
Apr 26, 2013, 3:15:16 PM4/26/13
to google-a...@googlegroups.com

On Friday, April 26, 2013 1:56:42 PM UTC-5, GAEfan wrote:
Could it be a version issue?  Backends does not yet have versioning.  But, how does it know which version of my app to access?  It should just default to the current.



It should hit the default version of your app.
 

So, I am getting a 301 at  " /_ah/start".  I do have a wildcard url handler (- url: /.*).  WIthout a "/_ah/start" handler in app.yaml, is it hitting the wildcard mapping before the built-in mapping?


Just for the sake of testing, remove the wildcard handler and change it to a specific path. But I doubt that will fix the problem, _ah/start urls are "special" urls. 

What is your initialization code doing?

GAEfan

unread,
Apr 26, 2013, 11:06:18 PM4/26/13
to google-a...@googlegroups.com
OK, so it IS the wildcard URL mapping:

- url: /.*

Removing this allows the backends to map properly.  Apparently, the wildcard url mapping short-circuits the backends mapping.  What is the default mapping for "/_ah/start"?  I shouldn't need to write a dummy handler for this.  I want to just state the default mapping explicitly.  I assume I also need to add "/_ah/stop"

Thanks.


Vinny P

unread,
Apr 27, 2013, 10:35:21 AM4/27/13
to google-a...@googlegroups.com
 /facepalm. It's always the most innocuous-looking statement that causes the most amount of trouble, isn't it?

Can you try replacing /.* with just /* and see if that works (in other words, remove the period in the middle).

GAEfan

unread,
Apr 27, 2013, 8:44:47 PM4/27/13
to google-a...@googlegroups.com
Hi Vinny:

I believe /.* is the proper syntax:


I do not understand the difference.  Both " /.* " and " /* " should mean "followed by 0 or more characters", but " /* " breaks my mapping for other urls.

Google Tasks Backup Moderator

unread,
Apr 27, 2013, 9:54:31 PM4/27/13
to google-a...@googlegroups.com
Asterisk means match zero or more of the preceding character

/.* means a forward-slash followed by zero or more characters. 
This matches the root, and any other page off the root (e.g. it matches both my-site.appspot.com/ and my-site.appspot.com/mypage)

/* means zero or more forward-slashes (which in reality only matches the root, because multiple forward slashes don't make sense)

URL and file path patterns use POSIX extended regular expression syntax

In app.yaml, always enter URL matches in the order of most specific to most generic, as GAE will run whichever script matches first.
Other commonly used URL matches are;
matches only the root URL (e.g. the home page, my-site.appspot.com/)
/.+ matches a forward-slash followed by one or more characters. (e.g. my-site.appspot.com/mypage)




--
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-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

GAEfan

unread,
Apr 29, 2013, 12:45:29 PM4/29/13
to google-a...@googlegroups.com
So I am back to my original dilemma.  My wildcard url mapping (/.*) is matching before (/_ah/start) and giving a 301.  So, what is the shortest way to get /_ah/start to return a 200, etc.?  I was hoping someone could just tell me the default mapping (as if there were no other match in the mapping in app.yaml.

Thanks.
Reply all
Reply to author
Forward
0 new messages