AppEngine 1.4.3 released: new file API, concurrent requests & more

http://googleappengine.blogspot.com/2011/03/announcing-app-engine-143-release_30.html

by yoda_sl • 15 years ago

76 27 15 years ago

googleappengine.blogspot.com

orijing• 15 years ago

Not to diminish the value of this release, but are there any improvements to consistency and availability of the data store?

mccutchen• 15 years ago

Hasn't this mostly been addressed by the High Replication Datastore?

davepeck5• 15 years ago

I suspect the answer is "yes" for most users.

My understanding of how it all fits together, please correct if wrong: the default datastore is (strongly!) consistent and partition tolerant but sacrifices availability. The new HRD gives you availability and partition tolerance at the cost, potentially, of consistency. You can get an intermediate state by wrapping writes in taskqueue tasks, which I do for writes that can wait but must not fail on the standard datastore.

davepeck5• 15 years ago

The testbed API is exciting -- testing (python) App Engine apps has always been thorny business.

It appears that support for integration testing, however, is not part of this release.

How do you integration test your (python) app engine apps?

Tools like nosegae + webtest give the _theoretical_ promise of integration testing by driving a WSGI app instance. Unfortunately, the _practice_ for any interesting App Engine app (especially those that call use_library for Django) is totally different. Basically, integration testing this way is completely broken: you end up in import error hell. This appears to be at least in part related to dev_appserver's (mis)use of Python's `imp` module, as described here: https://gist.github.com/883676#file_readme.md

bslatkin2• 15 years ago

That's a nice Gist. Not sure if you should send that to the NoseGAE folks or what. The dev_appserver follows PEP302 (http://www.python.org/dev/peps/pep-0302/) and should properly set attributes on sub-modules (i.e., assert 'subpackage' in dir(sys.modules['package']) ). The dev_appserver does not set those attributes explicitly, but the loader driving the PEP302 hook should.

davepeck5• 15 years ago

Interesting, thanks!

I'm afraid I'm having trouble parsing your statement on dev_appserver's behavior. Could you clarify it? It sounds like you're saying that dev_appserver both does and doesn't set submodule attributes on parent module instances. Where _should_ NoseGAE be doing this?

As far as I can tell, no code in the App Engine python SDK ever does this. In today's SDK, dev_appserver.py line 2256 adds the submodule to the sys.modules dictionary, but shouldn't there also be a line of code along the lines of setattr(sys.modules[parent_package_name], sub_package_name, submodule)?

Thanks for your help...

krosaen• 15 years ago

this comment helped me get around the import errors when using nosegae + webtest.

http://code.google.com/p/nose-gae/issues/detail?id=45#c1

totally a PITA but once it is working having a set of smoke tests for all of our urls is invaluable.

HowardRoark• 15 years ago

GAE Java only handled one request at a time till now?

teraflop• 15 years ago

One request per server instance. The change allows multiple threads to run in each instance, so now your code has to be threadsafe.

Smerity• 15 years ago

Your code only needs to be threadsafe if you wish to enable the concurrent flag, otherwise your code will happily run as it had before.

I just thought it's important to note that they're not forcing you to push a code update unless you want to handle concurrent requests with a single instance.

eneveu• 15 years ago

I was wondering about this in October, I guess the Vosao CMS needs to stop storing state in static fields now:

http://stackoverflow.com/questions/4028787/is-it-thread-safe...

Thilo added answer a few hours ago, pointing out the new threadsafe mode for GAE. That's why I like StackOverflow.

ShabbyDoo• 15 years ago

Wow. I'm not a GAE user, so I'm not embarrassed that I didn't know this. However, I'm surprised that such a restriction hasn't come up in all the blog entries I've read about GAE over the years.

space-monkey• 15 years ago

It's not a huge restriction since GAE will happily spin up dozens of instances without any intervention if your load requires it. Getting multiple concurrent requests into each instance will make things like local memory caching somewhat more useful though.

brown9-2• 15 years ago

I don't really recall seeing this spelled out clearly in the documentation before.

tybris• 15 years ago

That's pretty standard for Servlet containers.

yoda_sl• 15 years ago

One area that raise my interest is with the File API. I wonder if with the 'file' support it will be possible to get Lucene deployed onto GAE.

ww520• 15 years ago

The File API mapping to the Blobstore really simplifies blob support. The Blob datatype in Datastore has the 1M limit. It was kind of cumbersome to use both the Blobstore and Datastore API to store large objects.

BTW, the Java+Play!+GAE+Objectify really makes webapp development fun and fast.

netmau5• 15 years ago

Using Java+Play!+GAE+Twig for Sparkmuse and Im very happy with the stack overall. The new Blobstore API will help with handling image uploads which is something Play! On GAE fails at horribly (GAEs fault mostly).

herrherr• 15 years ago

I really hoped that they would release a full-text search for the datastore.

Guess I'll have to wait for that and use the improvised solution (http://billkatz.com/2009/6/Simple-Full-Text-Search-for-App-E...).

miloco• 15 years ago

Still no simple backup/restore feature. All I ask is for them to implement a dashboard based backup & restore tool!

AppEngine 1.4.3 released: new file API, concurrent requests & more

Related Stories