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.
> 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-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscribe@googlegroups.com<google-appengine%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en.
> 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.
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 16, 11:50 pm, mb <doit...@gmail.com> wrote:
> > 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.
> 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 16, 11:50 pm, mb <doit...@gmail.com> wrote:
> > > 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.
> On Mar 17, 9:07 am, Tristan <tristan.slomin...@gmail.com> wrote:
> > 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
> > On Mar 16, 11:50 pm, mb <doit...@gmail.com> wrote:
> > > > 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.
> 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.
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
On Wed, Mar 17, 2010 at 10:48 PM, prgmratlarge <yossiele...@gmail.com>wrote:
> On Mar 16, 11:31 pm, "Jason (Google)" <apija...@google.com> wrote: > > 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:
> > 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-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscribe@googlegroups.com<google-appengine%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en.
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)?
> 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
> On Wed, Mar 17, 2010 at 10:48 PM, prgmratlarge <yossiele...@gmail.com>wrote:
>> What are strong vs consistent reads?
>> On Mar 16, 11:31 pm, "Jason (Google)" <apija...@google.com> wrote: >> > 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:
>> > 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-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscribe@googlegroups.com<google-appengine%2Bunsubscrib e@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en.
> -- > 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-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscribe@googlegroups.com<google-appengine%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en.
> 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.
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/... .
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.
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/TransactionsAcrossDatacente... . 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.
