http://code.google.com/p/googleappengine/downloads/list
Both pre-release SDKs include RELEASE_NOTE files that indicate what's
new, but the App Engine back-ends have not yet been updated, so please
don't try to use these new features in production just yet. Please
test your existing applications locally using the new SDK and report
any bugs as soon as possible. Our next general release will likely
follow in the next couple of weeks barring any unforeseen issues.
Thanks,
- Jason
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
App Engine Python SDK - Release Notes
Version 1.3.2
=================================
- New API to read the contents of uploaded Blobs (fetch_data)
http://code.google.com/p/googleappengine/issues/detail?id=2536
- URLFetch now supports accessing ports 80-90, 440-450, and 1024-65535
- Mail API now allows common document formats as attachments
http://code.google.com/p/googleappengine/issues/detail?id=494
- The Task Queue API now supports adding multiple tasks in a single
call to
Queue.add()
- Fixed charset handling for inbound emails
http://code.google.com/p/googleappengine/issues/detail?id=2326
- Fixed issue with compositing background colors in dev_appserver
- New feature in the datastore to specify whether to use strong or
eventually
consistent reads (the default is strong)
- New datastore feature allows setting deadlines for operations
- Increased the maximum Task Queue refill rate from 20/s to 50/s
- Support for IP blacklisting to prevent denial of service (DoS)
attacks
- Fix an issue with Mac Launcher in Mac OSX 10.5.5
http://code.google.com/p/googleappengine/issues/detail?id=778
- Fix issue with slow updates when there are many skipped files
http://code.google.com/p/googleappengine/issues/detail?id=2492
- Fix issue with cursor not updating when using a GqlQuery
http://code.google.com/p/googleappengine/issues/detail?id=2757
Version 1.3.2
=============
- New API to read the contents of uploaded Blobs (fetch_data)
http://code.google.com/p/googleappengine/issues/detail?id=2536
- URLFetch now supports accessing ports 80-90, 440-450, and 1024-65535
- Mail API now allows common document formats as attachments
http://code.google.com/p/googleappengine/issues/detail?id=494
- The Task Queue API now supports adding multiple tasks in a single
call to
Queue.add()
- Fixed charset handling for inbound emails
http://code.google.com/p/googleappengine/issues/detail?id=2326
- Fixed issue with compositing background colors in dev_appserver
- New feature in the datastore to specify whether to use strong or
eventually
consistent reads (the default is strong)
- New datastore feature allows setting deadlines for operations
- Increased the maximum Task Queue refill rate from 20/s to 50/s
- Support for IP blacklisting to prevent denial of service (DoS)
attacks
- App Stats is now available for the Java SDK in addition to Python
- Fix issue with expiration times not being reset on Put on the
Memchache API
http://code.google.com/p/googleappengine/issues/detail?id=1284
- Fix issue preventing static files from being served when a servlet
is mapped to root
http://code.google.com/p/googleappengine/issues/detail?id=1379
On Mar 17, 5:39 am, George Moschovitis <george.moschovi...@gmail.com>
wrote:
> Seems like a *great* release!
>
> -g.
>
> --http://www.appenginejs.org
On Mar 17, 7:24 pm, Nickolas Daskalou <n...@daskalou.com> wrote:
> According to the post mortem from the last outage, the eventually consistent
> option will have higher latency (=bad) than the strongly consistent option,
> in exchange for higher availability during an unexpected failure (=good).
definitely good questions. there are two distinct features here that
are getting confused. the eventually consistent read feature in 1.3.2
is *not* the same as the "higher availability using synchronous
replication" feature described in the postmortem,
http://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf
.
the eventually consistent read feature in 1.3.2 only affects reads,
not writes. the current strongly consistent reads always read from the
primary replica. eventually consistent reads may also read from the
secondary replica, in cases when the data in the primary replica is
temporarily unavailable. in those cases, the secondary replica may not
have received the latest updates, so the returned data may be stale.
in other words, this increases availability at the cost of
consistency. the read may also be slower than usual, since the
secondary replica is usually farther away.
however, this eventually consistent read feature does *not* change the
datastore's current master/slave replication design described in
http://googleappengine.blogspot.com/2009/09/migration-to-better-datastore.html
. that means that it doesn't affect writes.
the upcoming synchronous replication feature described in the
postmortem is different. it only affects writes, not reads. we haven't
finalized the details yet, but at a high level, it will allow you to
write atomically to multiple replicas at once, using paxos, as
described in http://code.google.com/events/io/sessions/TransactionsAcrossDatacenters.html
. this will increase write latency, but will provide additional safety
against outages. incidentally, it will also mean that eventually
consistent reads of data written with synchronous replication will
*always* return the most recent data.
----------
keakon