2
votes

App engine "modules" are a new (and experimental, and confusingly-named) feature in App Engine: https://developers.google.com/appengine/docs/python/modules. Developers are being urged to convert use of the "backends" feature to use of this new feature.

There seem to be two ways to start an instance of a module: to send a HTTP request to it (i.e. at http://modulename.appname.appspot.com for the appname application and modulename module), or to call google.appengine.api.modules.start_module().

The Simple Way

The simple way to start an instance of a module would seem to be to create an HTTP request. However, in my case this results in only two outcomes, neither of which is what I want:

  • If I use the name of the backend that my application defines, i.e. http://backend.appname.appspot.com, the request is properly routed to the backend and properly denied (because backend access is defined by default to be private).

  • Anything else results in the request being routed to the sole frontend instance of the default module, even using random character strings as module names, such as http://sdlsdjfsldfsdf.appname.appspot.com. This even holds for made-up instance IDs such as in the case of http://99.sdlsdjfsldfsdf.appname.appspot.com, etc. And of course (this is the problem) for the actual name of my module as well.

Starting via the API

The documentation says that calling start_module() with the name of a module and version should cause the specified version of the specified module to start up. However, I'm getting an UnexpectedStateError whenever I call this function with valid arguments.

The Unfortunate State of Affairs

Because I can't get this to work, I'm wondering if there is some subtlety that the documentation might not have mentioned. My setup is pretty straightforward, so I'm wondering if this is a widespread problem to which someone has found a solution.

3
The way I see modules, they are not something that are started. Instead, it is a way to partition your app into different logical units, e.g. a web and api part of your app. As such, one way of looking at modules is several apps in one app that all share resources such as datastore and memcache. In the Python example, there is no mention of starting a module. They just have different urls. - dlebech
But in the admin dashboard, you can view the instances that have been started for your app, and each instance is associated with a module and a version. (In fact, you select a module and a version and can then view any instances associated with that pair.) And when you are viewing instances, you can shut them down... so they got started somehow. - Jeremy
Instances are automatically started when a request is made to your app. In the case of modules, my guess is that it works the same: Instances for a module are automatically started when a request is made for a url that is served by a module. Of course you can set some idle instances (under application settings) and you can probably also start instances on demand (to a certain extent) but generally, it happens automatically and is not something specific for modules. Again, this is based on my understanding so I could be wrong. - dlebech
I suppose that it is really an instance of the version of the module which is supposed to be starting up. Nevertheless, the call returns an error, nothing starts up, and my code doesn't run.... - Jeremy

3 Answers

3
votes

It turns out that versions cannot be numeric. This problem seems to have been happening because our module's version was "1" and not (for example) "v1".

0
votes

With modules, they changed the terminology around a little bit. What used to be "backends" are now "basic scaling" or "manual scaling" instances.

"Automatic scaling" and "basic scaling" instances start when they process a request, while "manual scaling" instances run constantly.

Generally to start an instance you would send an HTTP request to your module's URL.

start_module() seems to have limited use for modules with "manual scaling" instances, or restarting modules that have been stopped with stop_module().

0
votes

You can add:

login: admin

To the handler for your backend. This way an admin user can call your backend and trigger it to run. With login: admin, you can also have issue URLFetch requests froom elsewhwere in your app (ie from a frontend) trigger your backend.