Wednesday, March 30, 2011

Announcing App Engine 1.4.3. Release

Just in time for spring, we have a new App Engine release to bring our Java and Python runtimes even closer to parity. For Python, we’ve launched a test library to match the existing Java testing framework, and for Java we’ve introduced the Deferred and Remote APIs. This release also introduces a new Blobstore writing feature, the experimental release of the Prospective Search API in Python, and a few goodies for Task Queue and Cron users.

Python

  • Prospective Search API: The experimental Prospective Search API allows Python runtime users to detect and take action on datastore entities that match certain criteria when they are written. For the experimental release, users will be allowed 10,000 subscriptions with the Prospective Search API. Pricing will be announced once the feature is fully launched.
  • Testbed Unit Test Framework: The Testbed suite for Python provides an easy interface for using App Engine API stubs in integration tests similar to the previously existing Java Testing Framework. You can create tests for your application that do not rely on calling App Engine production services, which speeds up the time your tests take to complete, and eliminates dependencies for your test on external services. Here at Google, we’re well known for our testing culture, and we hope that this API will allow you to develop more stable code more quickly.

Java

  • Concurrent Requests: Until now, Java applications relied on starting additional instances to dynamically scale up for higher traffic levels. Now with support for concurrent requests, each application instance may serve multiple user requests at the same time. To start, ensure your application’s code is threadsafe, then enable concurrent requests by adding the <threadsafe> flag to your appengine-web.xml.
  • Java Remote API and Deferred API support: The Remote API and Deferred API libraries have been supported in Python for awhile, and now they can be used with Java, too! The Remote API allows you to perform operations on your application’s datastore from your local machine. This is particularly useful for work that is not well-suited to App Engine’s request/response model. The Deferred API allows users to more easily write and execute ad hoc tasks. Our docs contain more information and examples on how to use the Remote API and Deferred API in Java App Engine.

New and changed APIs

  • Files API: The new Files API in Python and Java allow you to programatically read and write data using Blobstore. This API can be used to generate reports, export data, or do anything that your heart desires that requires large, binary objects.

Serving Changes

  • Task Queue and Cron update: We’ve addressed some of your top requested items for Task Queues and Cron. With this release, you can now configure the specific application version to which a task queue or cron job will send requests. For those wanting to schedule cron jobs with a range syntax like “every 5 minutes from 11:00 to 17:00”, that too is available in the 1.4.3 release. Last, but not least, the Admin Console Task Queues page now displays a more accurate estimate of queue size for queues containing more than 2000 tasks.

Coming soon

Finally, we have a pre-announcement about the 1.4.4 release. In 1.4.0, we introduced a feature that allowed users to download code that they’ve deployed to App Engine. In 1.4.2 we released admin roles allowing for Owners. When 1.4.4 is released, we plan on including a change that allows both the person who uploaded the code to download it, as well as the Owner(s) of the project (as listed in the Admin Console). In preparation for this, be sure to properly assign roles to all developers on your App Engine application in the Admin Console. Alternatively, you will still be able to permanently disable the code download feature for your application.

That’s it for now, for additional information read the full release notes, including all new features and issues fixed for Java and Python. All feedback is welcome and encouraged in our groups.

25 comments:

Sargis said...

The ability to download production code would be really great. Looking forward for that!

Ronoaldo Pereira said...

Great news! The ability to write to Blobstore will save me a lot of time, and make obsolete my hand made in-memory/datastore file storage.

Congratunations AppEngine Team!

!Momo.の极乐世界 said...

Great!

- said...

Excellent Thanks!

sombriks said...

seriously, still waiting JDBC. It seems crippled without it.

Brandon Donnelson said...

Good Job!!! I'm looking forward to the blob reader.

http://code.google.com/p/gwt-examples/wiki/DemoGAEMultiFileBlobUpload

K said...

Thank you for Blobstore. You guys are seriously awesome.

Damian del Rivero Lagunes said...

What are the pros of enabling Concurrent Requests over the current scaling algorithm GAE uses??
Guess the billing on CPU time about loading requests will be lower.
I didn't know http requests were actually handled serially (each by an entirely new instance of the app).

So by enabling threadsafe I will be able to handle more requests with less instances and less warm requests and less loading requests??

Anonymous said...

Having a link to this page or some other release notes in the Google Software Update notifier would be nice, rather than forcing me to google it....

Nik said...

Is there any news about integration GAE + Google Storage For Developers?

Anonymous said...

Again... awesome!

Admin said...

Good work, I have also noticied that java deployment takes less time..

Unknown said...

Thank you guys! Awesome work as always, looking forward to using the Testbed and the new blobstore API.

Safi said...

I didn't know http requests were actually handled in a Single-Thread Model on GAE. o_O

I guess very few has written/deployed code that requires (is based on) a STM. Thus almost everybody could simply enable <threadsafe>, right?

Unknown said...

Java technology is built on the premise that Servlets/JSP are multi-threaded by by default - it is the developer's responsibility to synchronize single-threaded code. Multi-tier webapps are most often architected to be thread safe: from DAO's in the data access tier to Service classes in the business tier and Controller classes in the presentation tier. Popular web frameworks like Spring MVC and Struts are built thread-safe.

Not treating Servlets/JSPs as threadsafe increases compute resource utilization (costs) and hurts performance.

I'm really surprised to hear that GAE has been serializing HTTP requests to Java webapps all this time. Or am I missing something here. Does the appengine-web.xml element "<threadsafe>true</threadsafe>" mean something else?

Steve Armstrong said...

GAE/j really wasn't multi-threaded until now? What's required once you turn on multi-threading? Is it just the standard servlet behaviour of a single servlet instance getting multiple concurrent calls to doGet() or doPost()? If so, I'm surprised this hasn't been the default this whole time.

Brandon Donnelson said...

The update seems that it takes a day or two to make it to the eclipse update channel.
http://gwt-examples.googlecode.com

Don said...

Damian: That's exactly correct. Enabling concurrent requests should decrease the number of loading requests, and therefore your overall CPU usage. It may also make local heap-based caches more effective. The only potential cons are that you may run into concurrency issues in your own code or frameworks or libraries that you depend on. If you are using a large amount of heap space for the duration of each request you may also run into memory contention that was not previously possible.

Safi: I would hope that you are correct (that almost everyone can safely turn on ), especially considering that the DevAppServer has always executed requests concurrently. However, we cannot rule out the possibility of deadlocks or other concurrency bugs in widely-used libraries built for App Engine so we decided to make this an opt-in feature.

s, Steve: We expected this to be somewhat surprising to many Java developers. However, please keep in mind that we have always scaled your application out to a potentially very large number of processes and machines, depending on its load. Executing in multiple threads within each process just allows us to do so with less RAM usage (something that we don't currently charge for) and with fewer loading requests.

Chris Dance said...

Regarding the concurrent request - does anyone know how the python environment is handled at the moment?

Unknown said...

I'm trying to use File API to store files to Blobstore but keep getting java.lang.ClassNotFoundException: com.google.appengine.api.files.FileServiceFactory on my local development server.

Any ideas?

Good work with including File API btw! Hopefully it works on dev. server too.

Jayr Motta said...

GREAT!

Michal Hantl said...

Concurrent requests? Holy crap!
... You guys rock!

Unknown said...

Really need https support for apps domains. We using Vosao, but it's not usable in secure projects now :( vosao.ogr

Unknown said...

I am trying to use the Remote API for java and I get the following error: java.lang.NoClassDefFoundError: Could not initialize class com.google.appengine.tools.remoteapi.RemoteApiInstaller

Anyone knows why?

hirosi said...

I want to use "like %word%" in Database.
Is it any reason?