Pre-release 1.3.2 SDKs available

[Jason (Google)]

Hi Everyone. Just a quick note that we just uploaded pre-release 1.3.2
SDKs for Python and Java to our Google Code project page:

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

[Nickolas Daskalou]

From the release notes:

"New feature in the datastore to specify whether to use strong or eventually consistent reads (the default is strong)"

Didn't think this would be out for quite a while. Very, very cool. :)

--
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.

[mb]

Wow, this is a substantial release!

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

[Tristan]

App Engine Java 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

- 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

[Prashant Gupta]

any update on blob store access/quota for free accounts ?

[George Moschovitis]

Seems like a *great* release!

-g.

--
http://www.appenginejs.org

[bFlood]

agreed, some great stuff in there! congrats!

On Mar 17, 5:39 am, George Moschovitis <george.moschovi...@gmail.com>
wrote:

> Seems like a *great* release!
>
> -g.
>

> --http://www.appenginejs.org

[Joseph Lebel]

What are strong vs consistent reads?

[Alkis Evlogimenos ('Αλκης Ευλογημένος)]

Strong means all replicas will have the updates after a write returns and all reads after the write will "see" those updates.

Consistent (or eventually consistent) means that all replicas will eventually have the updates after a write and some reads after the write will "see" stale/previous versions of the data.

Basically it boils down to trading correctness (possibility of stale reads) for better performance.

- alkis

[Nickolas Daskalou]

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).

From the post mortem:

"In response to this outage, we have also decided to make a major

infrastructural change in App Engine. Currently, App Engine provides a

one-size-fits-all Datastore, that provides low write latency combined

with strong consistency, in exchange for lower availability in

situations of unexpected failure in one of our serving datacenters. In

response to this outage, and feedback from our users, we have begun

work on providing two different Datastore configurations:

- The current option of low-latency, strong consistency, and lower

availability during unexpected failures (like a power outage)

- A new option for higher availability using synchronous replication

for reads and writes, at the cost of significantly higher latency"

Can someone from Google please answer these questions:

With the eventually consistent option, will both Datastore reads and writes have higher latency, or just writes?

Does the higher availability of the eventually consistent option only apply to Datastore reads (ie. writes will have the same availability as with the strongly consistent option during outages)?

Nick

2010/3/18 Alkis Evlogimenos ('Αλκης Ευλογημένος) <evlog...@gmail.com>

[PK]

Just writing to report that I have not tried any of the new features
but at a minimum my regression tests passed. Thanks and keep up the
good work!!

PK
www.gae123.com

[ryan]

On Mar 17, 4:29 pm, Alkis Evlogimenos <evlogime...@gmail.com> wrote:
> Strong means all replicas will have the updates after a write returns and
> all reads after the write will "see" those updates.

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.

[ryan]

btw, i just wrote a related post on why we're offering these options
at all:

http://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf#388f334236edaeaf

[风笑雪]

I hope urlfetch can support the default ftp port (21), and increase
the max response size to 10MB.

----------
keakon