顯示具有 GAE 標籤的文章。 顯示所有文章
顯示具有 GAE 標籤的文章。 顯示所有文章

2014-01-07

GAE 的 static file 不會觸發 filter?

一直以來 JSP Filter 用得好好的,結果前幾天一直被炸, index.html 始終不會觸發 Filter.doFilter(); 但是只要換成 JSP 或是 Servlet 就沒事,正常得很。

本來懷疑是 GPE 的問題,結果丟上 GAE 也是一樣的情況。 後來重開乾淨的純 GWT project 跟純 GAE project 比對, 發現只要有用 GAE SDK 的 project 就會有這個現象, 看起來就不像是 bug 了 XD

胡亂繞了一下,終於找到癥結點了。 首先是 GAE 文件講到 web.xml 時說:

Note: Static files, files that are served verbatim to users such as images, CSS or JavaScript, are handled separately from paths mentioned in the deployment descriptor. A request for a URL path that matches a path to a file in the WAR that’s considered a static file will serve the file, regardless of servlet and filter mappings in the deployment descriptor. You can exclude files from those treated as static files using the appengine-web.xml file.

搭配 appengine-web.xml 的這段一起看:

These are known as static files because they do not change, and can benefit from web servers dedicated just to static content. App Engine serves static files from dedicated servers and caches that are separate from the application servers.

[…]

By default, all files in the WAR are treated as both static files and resource files, except for JSP files, which are compiled into servlet classes and mapped to URL paths, and files in the WEB-INF/ directory, which are never served as static files and always available to the app as resource files.

簡單地說,就是除了 JSP 跟 WEB-INF 底下的東西,其他預設都會當成 static file。 而 static file 因為都不會變、所以可以作一些特別處理來優化效能。 所以 index.html 始終不觸發 doFilter(),也就完全合情合理了。 於是只要照著把 index.html 排除在外,就會觸發 doFilter() 了:

<static-files>
    <exclude path="index.html" />
</static-files>

把人家刻意優化的東西當成 bug,實在太丟臉了。 所以這篇貼在 PT2Club 就算了,不要拿到 DontCare Blog 上丟人現眼 [遮臉]

(謎之聲:干有差? [指])

2012-02-04

猜不透的 Datastore Admin......

前幾天無聊亂逛 GAE 的管理功能,Datastore Admin 要好~~久才會跑出來,看到有 Delete Entities 的功能,想說那來砍 _ah_session 看看,之前掛了 SessionCleanupServlet
似乎沒什麼效果,可是系統已經很久沒有用 session,實在頗怪。雖然壓根談不上爆 storage quota,不過基於龜毛,沒用的東西砍一砍比較清爽...... \囧/

喔...... 要跑 MapReduce? 那就跑啊... 反正也才 5MB 大、沒多少資料,應該不打緊。接著跳出一堆看不懂的表格,實際去 Datastore Viewer 看... _ah_session 的東西還是在,還多了幾個奇怪的 datastore...... 等等......
為甚麼本來沒多少的 Datastore Write Operations
瞬間 100% 啊 <囧>
然後隔了一天 _ah_session 才真正清光光(Datastore Write Operations 沒有再爆炸了)、隔了兩天那些奇怪的 datastore 才統統不見...... 真是猜不透... 猜不透啊...... Orz

下次還是自己寫刪除功能好了...... 囧>

2011-11-28

我所用的免費開發工具

「如果開發工具就是要我們付一堆錢,那我就讓你們看見窮人的驕傲」

  • JavaSE:從 Sun 到 Oracle,至少官方的 JVM 與 SDK 都還是免費下載使用。
  • Eclipse:以 Java Programmer 來說,這是一套很完整的 IDE。code assist、JavaDoc...... 到 Refactory 的功能(自從有了 rename 功能之後,變數名稱都可以亂取了呢... [毆飛])都無須安裝 plugin 就具備。如果以「我只是想寫個簡單的 Java」角度來說,可能還會有點嫌棄裡頭有太多東西了(瞧瞧那精美的 Ant、Maven、Mylyn......)
  • Google Plugin for Eclipse(GPE):包含 GWT、GAE 的 SDK 與 GAE 的 local runtime 以及整合 GWT 的 deploy 工具。GWT 裡頭還提供了 GWT Designer 這個處理 layout 的 UI 工具。現在還整合 Google Code、Google API....... 統統不用錢。btw... 其實 GWT Designer 本來是商業軟體,後來被 Google 買下來之後就......
再加上用 Google Doc (算是能)解決 M$ Office 的檔案問題,買 Notebook 本來就附贈 Windows 的版權(我沒厲害到想去用 Linux 或是 Mac),電腦打開來,還真的沒什麼值錢的軟體...... 

這就是窮人的驕傲 [炸]

2011-10-12

App Engine 1.5.5 版發佈

App Engine 在 2011 年釋出了一些令人興奮的版本。隨著白天越來越短、天氣越來越冷、雜貨店裡頭的萬聖節糖果開始引誘人變胖,我們也一直努力讓最新的版本能順利推出。

高級帳戶
在為最關鍵的商業 application 選擇運作平台時,我們認為「保證可運行時間」、「管理容易」與「付費的支援」跟產品的功能一樣重要。 因此,我們開始推出 Google App Engine 的高級帳戶。每月支付 500 美元(不包含 internet service 的費用),將會下列這些功能:
  • 專屬的技術支援服務(細節參閱技術支持服務指南)。
  • 「保證 service 在 99.95% 的時間中是可運作」協定(參閱協定草稿,最終版會 be in the signed offline agreement)。
  • 在高級帳戶的 domain 下,applicaion 的數量沒有上限。
  • 每個 application 沒有最低月租費,只要負擔你所使用的 resource 費用就好。
  • 以發票按月結算。
要註冊為高級帳戶,請與我們的銷售團隊聯繫:appengine_premier_requests@google.com。

支援 Python 2.7 版
PIL?NumPy?concurrent request?這些 Python 2.7 版全部都有。今天我們實驗性地開放支援 Python 2.7 版。2.7 與 2.5 版執行環境的差異,我們已經都放到已知差異整理列表當中。

整體性的更新
我們知道卡在硬性的系統限制當中是多麼令人沮喪的事情,所以今年一整年持續在提昇我們的系統限制。在這個版本當中,我們又擴增了一些東東:
  • request 的持續時間:前端 request 的 deadline 已經從 30 秒增加到 60 秒。URLFetch 的最大 deadline 也從 10 秒增加到 60 秒。
  • 檔案限制:我們增加了一個 application 所能上傳的(靜態)檔案數量,從 3000 增加到 10000,並且大小的限制也從 10MB 增加到 32MB。
  • API 限制:現在 URLFetch 的 Post payload 上限從 1MB 改為 5MB。
另外,我們也宣佈幾個封測階段的功能、與委託測試的計畫:
  • Cloud SQL:我們上週宣布在 App Engine 中支援 SQL。請試試看,並告訴我們你的想法。
  • 全文檢索:我們正在找尋前期的委託測試者,來測試期望很久的全文搜尋 API。如果你有興趣嘗試它,請填寫這個表格。
  • Conversion API:曾想要在 application 當中將文字輸出成 PDF 嗎?請考慮報名成為 Conversion API 的委託測試者。
Datastore
  • Cross Group(XG)Transaction:對於需要對多個 entity group 的 entity 作寫入 transaction 的人(其實就是每個人吧?),那就用 XG Transcation 吧。 這個功能需要兩段式的 commit,好讓跨 group 的 write atomic 可以就像單一 group 的寫入行為。
平台改進
當然,這裡列出來是比較上層的改變。這個版本也包含完整的功能與錯誤修復。一如往常,我們歡迎在 Google Group 中看到你的回饋意見。

2011-10-08

Google Cloud SQL:你的雲端資料庫


原文網址:http://googleappengine.blogspot.com/2011/10/google-cloud-sql-your-database-in-cloud.html

「提供一個可以簡單開發傳統資料庫應用程式的方法」是最常要求 App Engine 提供的功能之一。為了回應這些聲浪,我們很高興地宣佈 Google Cloud SQL 有限制地開放試用。現在你可以選擇讓 App Engine 的 application 使用完全在雲端當中但卻是熟悉的 relational database。這讓你能專注在開發 application 與 service,至於管理、維護 relational database 的雜事統統不用管。Google Cloud SQL 帶給 App Engine 社群許多好處:

  • 不用維護、也不用管理——我們都幫你處理了。
  • 高可靠度與可用度——你的資料會同步複製到多個 data center。機器、機架與 data center 的故障都會自動處理,盡可能地避免影響到 end user。
  • 熟悉的 MySQL database 環境,有支援 Java 的 JDBC、也有支援 Python 的 DB-API。
  • 綜合式的管理 database 使用者介面。
  • 簡單卻完全與 App Engine 整合。

這個 service 也包括了 database 匯入/匯出的功能,所以你可以把你既有的 MySQL 送上雲端,然後在 App Engine 當中使用。Cloud SQL 現在是免費提供,我們會在至少開始收費前 30 天公佈價格。在我們解決初期大小問題的同時也會持續改進這個 service,如果你想拿來試試看,請讓我們知道。

2011-09-28

用 Channel API 實作簡易聊天室

Google App Engine 自 1.4.0 版推出 Channel API,使 server 與 browser 之間可以不透過 pooling 的方式做到 server push。不過 Google 官方教學文件摻雜了井字遊戲的元素,反而無法專注於 Channel API 上。這篇文章打算用最原始的聊天室,透過實做的過程來體驗一下 Java 版 Channel API。

因為是簡易聊天室,所以只打算提供一個共用的聊天室,然後用兩個 JSP 檔來解決:room.jsp、server.jsp。room.jsp  負責處理使用者輸入訊息、顯示對話;server.jsp(應該寫成 servlet 比較好,因為是簡易聊天室......)負責接收訊息、並廣播出去。

對應到 Channel API 的用詞,一個聊天室就是一個 channel,同一個 channel 的成員(client 端)就會接收到其他成員所發出的訊息(message)。所以,從 server 的角度,需要作這些事情:
  1. 開啟一個 channel
  2. 給加入這個 channel 的 client 專屬識別碼(token)
  3. 接收訊息的管道
  4. 發送訊息的功能
在 Channel API 當中只要決定 channel 的 名字就算做到第一點了,因為是簡易聊天室,所以把名稱訂死為「PsMonkey」。產生 token 的方法是:
//Java code
ChannelService channel = ChannelServiceFactory.getChannelService();
String token = channel.createChannel("PsMonkey");

因為是簡易聊天室,所以把 token 透過 JSP 產生、並塞進 client 端的 JavaScript 碼。

接下來看 client 端的部份。首先建立連線的部份:
//JavaScript code
var channel = new goog.appengine.Channel("<%=token%>");  //token 傳入
var handler = {
	'onopen' : onOpened,  //建立連線、channel.open() 就會觸發
	'onmessage' : onMessage,  //有訊息傳入時
	'onerror' : onError,  //發生錯誤時
	'onclose' : onClosed,  //連線結束時
};
socket = channel.open(handler);

socket 就是實際處理通訊的部份。這段的重點是透過 handler 設訂 socket 各種狀況會觸發的 method。仔細想一下就會發現:「只有接收訊息的 method,那傳送訊息呢?」

Channel API 要解決的問題是 server push,client 端傳送訊息的功能並不包含在其中,得透過 HTTP request 來作到。所以送訊息的 method 會長的像這樣:
//JavaScript code
sendMessage = function(message) {
	var xhr = new XMLHttpRequest();
	xhr.open('POST', 'server.jsp?msg='+message, true);
	xhr.send();
};

於是用 sendMessage() 來設定在 client 端連線時送出「____ 進入聊天室」、離線時送出「____ 離開聊天室」:
//JavaScript code
onOpened = function() {
	sendMessage("「"+name + "」進入聊天室......");
};

onClosed = function(){
	sendMessage("「"+name + "」離開聊天室......");
}

有訊息進來的時候,就把訊息塞進某一個 element 的尾巴。這邊要注意一點,參數 msg 不是單純的字串,而是一個物件,data 這個 field 才是真正回傳的資料。
//JavaScript code
onMessage = function(msg) {
	document.getElementById("output").innerHTML += msg.data +"<br />";
}

接著來看一下負責處理 client 端 sendMessage() 的 server.jsp,直接貼程式碼:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@page import="com.google.appengine.api.channel.*"%>
<%
String message = request.getParameter("msg");
ChannelService channel = ChannelServiceFactory.getChannelService();
channel.sendMessage(
	new ChannelMessage("PsMonkey", message)
);
%>

在從 request 當中取得 clinet 端傳上來的訊息後,連同 channel 的名稱包成一個  ChannelMessage,透過 ChannelService.sendMessage() 傳出去,就會觸發 client 端的 socket.onMessage 了。

再透過一些簡單的 HTML 與 JavaScript 來讓 client 端送出訊息時能呼叫到 sendMessage(),聊天室就完成了!是不是很簡單呢? [扭扭]

最後補充 socket 的幾件事情:

  • onerror 會傳入一個參數,其中有兩個 field:
    • description:錯誤的描述
    • code:HTTP 錯誤代碼
    • 目前只測出 idle 太久、server 切斷連線時會觸發
  • socket 還有一個 method:close(),呼叫成功會觸發 socket.onclose。
完整可以跑的範例放在這裡...

2011-09-16

App Engine 1.5.4 版發佈


原文網址:http://googleappengine.blogspot.com/2011/09/app-engine-154-sdk-release.html

這四個禮拜真的是忙翻啦(你可能有聽說),但我們仍然保持每個月發佈新版本的期程。今天我們提供了新的 SDK,以及一些新功能和錯誤修正。

整體更新
  • Blobstore API——我們加入了一個選項,讓你可以指定上傳 blob 的大小限制。這個功能讓你可以接觸到使用者上傳的 blob,同時也可以確保他們上傳的東西沒有超過你預設的限制。
  • Datastore 查詢改進——我們延續過去幾個版本的主題,調整 Datastore 的查詢規劃,讓使用者感覺更靈活。從 1.5.4 版開始,對多個 property 作 filter 的查詢,會持續運作直到 Datastore 的查詢時間上限(高達 30 秒!)。過去,許多這類的查詢都會因為沒有效率的 index 而導致產生錯誤,現在則會運作正常。
  • 在 SDK 中顯示 Datastore 寫入次數——依據最近改版為 Side by Side 帳單時所得到的回饋意見,現在我們會在 SDK 的 dataviewer 當中顯示儲存一個 entity 需要的寫入次數。寫入的次數包含寫入 entity、以及增加 entity 時 index 的寫入。你可以透過把 index 的 property 調整成 unindex 的 properties,來降低寫入的次數,只要確定你沒有在其他 query 當中參考到這些 property 就好。(參考 Java 與 Python 的相關 API)
Java
  • Prospective Search API——我們發佈了實驗性質、Java 版本的 Prospective Search API。這讓你在符合某些條件的資料被寫入到 Datastore 時,能偵測到、並有所作為。
Python
  • Memcache——你現在可以非同步呼叫 Memcache API。有了非同步的 Memcache,你的 application 就不會在呼叫 Memcache 時被 block 住,可以繼續處理 request 而不用等待 Memcache 的回應。寫 Java 的朋友們也不要擔心,我們即將釋出的版本會有對應的功能。
在老地方(Java 版,Python 版)可以找到完整的版本更新紀錄。你們在 Google Group 提出的回饋意見,我們都會仔細閱讀。祝 coding 快樂!

2011-09-08

App Engine 1.5.3 版發佈


原文網址:http://googleappengine.blogspot.com/2011/08/app-engine-153-sdk-released.html

今天,我們很高興地宣佈新版的 App Engine 發佈了。你可能有注意到,在過去幾個月中,版本更新的頻率略有上升。我們做了一些內部改組,期待能每個月推出一個新版本。這個月的更新包含了一些 datastore 的更新、一些 blobstore API、memcache API 的更新,以及一個針對 Java 開發者的新功能。

Python 與 Java 的改變
  • blobstore API——我們已經取消 blob 上傳的大小限制。你現在可以上傳任何大小的檔案,讓你的 application 可以處理圖片、影片、或任何 internet 連線可以處理的東西。

datastore 的改變
  • 取回索引——對現存於 datastore 的索引,我們加上了讓你可以用程式取回索引列表及狀態的功能。
  • datastore 管理——現在你可以在 Admin Console 啟用 datastore 管理功能。這讓 Java 使用者可以做到「刪除某一類下的所有 entity」的功能,而無須上傳 Python 版的 application。對於 Python 的開發人員而言,這表示你不用再到 app.yaml 檔裡頭將這個功能開啟。
  • HRD 整合的可靠測試者——我們正在找尋前期就採用 HRD 的人,來實驗強化 HRD 整合的工具。這個工具需要一段唯讀時間,這段時間與你的 datastore 寫入頻率有關(目前這個版本的行為是相對於 datastore 的大小)。請參閱版本更新紀錄,裡頭有更多資訊。(謎之聲:這是哪門子的版本更新 ==")

Python 的更新
  • memcache API——我們在 Python 的 memcache API 當中支援 CAS(compare-and-swap,比較並替換)的操作方式(Java 已經有了)。當你取值回來並要更新它時,這個操作讓你可以在沒有其他更新的 request 時,才作更新的動作。

Java 的更新
  • 下載 application——使用 AppCfg download_app 指令,你可以下載上次更新版本當中,war 目錄下的任何檔案。

這個版本還包含一些微幅的更新與錯誤修正(無論是 Python 版或 Java 版),所以一定要參閱完整的版本更新紀錄。回饋意見與問題討論都可以在我們的 Google Group 當中發表。

2011-09-06

App Engine 1.5.2 版發佈

原文網址:http://googleappengine.blogspot.com/2011/07/app-engine-152-sdk-released.html

server 產能的更新
  • 可調整的 Scheduler 參數 - 正如之前討論過,我們推出了兩款 scheduler 旋鈕(好吧,實際上看起來比較像滑動軸),讓你能控制有多少 instance 在 application 上執行的參數。現在,你將可以設定 panding latency 的最小值、以及閒置 instance 的最大量。

Datastore 的更新
  • 進階 query 計畫 - 我們移除了爆量索引的需要、也減少了許多 query 要自訂 index 的需求。在許多狀況下 SDK 會建議更佳的索引方式,接下來的文章也會介紹如何進一步最佳化。
  • namespace 層級的 datastore 統計資料:現在除了取得全部的 datastore 統計資料,我們也提供一個新的選擇,讓你可以以 namespace 來查詢。

Task Queue 的更新
  • 新的 Task Queue 細目頁面——我們改寫了 Administration Console 裡的 Task Queue 細目頁面,提供了執行中的 task 的更多資訊。你現在可以看到排隊中的 task、有效承載量、以及前一個執行 task 的資料。
  • 1MB 的 Pull Task 容量——對於容量大小的限制,我們的信念就是:只能變得越來越大!所以,在這個版本當中,我們把 Pull Task 的容量變成 1MB。
  • Pull Queue 時效變更——針對 Pull Queue 我們推出了新的 method,如果當初設定的時效不足時,讓你可以將現有的 task 延長時效。

最後,我們有一些令人振奮的消息是關於實驗中 Go 執行環境。雖然 Go 仍然在實驗階段,但從 1.5.2 之後,Go 將可以存取所有 HRD 的 application。

一如往常,也有一些小功能與錯誤修復,在我們的版本更新紀錄當中可以找到完整的清單(Python 版,Java 版)。我們期待在論壇當中看到您的回饋意見與問題。

2011-07-04

App Engine 1.5.1 版發佈

原文網址:http://googleappengine.blogspot.com/2011/06/app-engine-151-release.html


Google I/O 已經結束一個月,所以我們覺得應該再來個版本發佈了。這個月我們發佈 ProtoRPC 這個正式的 Python API;讓 SDK 有 HRD(High Replication Datastore)的功能,協助開發者更能理解同步 model;另外增加了 Channel API、以及一些好東西。列舉如下:

service 變更

  • 地理定位 header:App Engine 現在會在每個 client 的 request 當中夾帶 header,來盡可能地分辨是哪一個國家發出的 request。「X-AppEngine-country」這個 header 可以讓你依照使用者的所在地來客製化內容。我們希望這代表使用者不用再到「你的國家」下拉選單當中選擇。

更新 Java 和 Python 的 API

  • Channel API(支援 Presence):現在你可以為你的 application 設定內建的 service,來偵測使用者的 presence。這讓你可以在使用者連線或斷線時作對應的行為。
  • Image API(支援 WebP):Image API 現在支援 WebP 格式。WebP 是一種新的圖像格式,Google 在今年初的時候開放原始碼。這個格式是用破壞性壓縮的方式,可以比 JPEG 格式檔案小 39% 、卻提供相同的畫質。

新的 Python API

  • ProtoRPC: ProtoRPC 是一個 open source 的 frame,用來建立一個良好定義、易於使用、web base 的 RPC service。雖然 ProtoRPC 跟 Google Protocol Buffers 定義 service 差不多,但 ProtoRPC 的目標是讓開發人員更容易開始定義 web base 的 service,同時允許這些 service 隨著時間改變而能逐步成型與拓展。

Datastore

  • SDK 中的 HRD:從發佈 HRD時,我們就希望能提供工具、幫助開發人員在設計 application 時了解和測試新的同步 model。1.5.1 SDK(Java 與 Python 版)可以模擬 HRD 的同步 model。這表示在設定對應的 SDK 選項後,跨 entity group 的查詢結果,偶爾會與剛寫入的資料有出入。這應該會讓你開發的過程中,處理這個同步 model 更加靈活。

(最後一段懶得翻譯 [逃])

2011-05-16

App Engine 1.5.0 版發佈

原文網址:http://googleappengine.blogspot.com/2011/05/app-engine-150-release.html

App Engine 團隊一直在拼命準備 Google I/O,而今天我們很高興地宣佈 App Engine 1.5.0——夾帶著一堆完成的新功能——正式發佈了。這個版本帶來了全新的特性:引入了 Backend、Task Queue 的重大改進、全新實驗性質的 Go 語言運行環境、High Replication Datastore 變成預設的設定(價格也降低了!),以及許多調整與 bug 修復。

service 變更
  • Backend:截至目前為止,App Engine application 是在一個短暫存在、動態的 instance 上頭運作,我們啟動它來回應 request 然後再關掉它。這對於建構可擴增的 web application 是很棒的事,但是如果你在找尋建立大型、長時間存活、以及/或密集存取記憶體的底層功能,就會有很多限制。在 1.5.0 版,我們引入了 Backend,讓使用者可以打破這樣的限制!Backend 是由開發人員控制、長時間運行、可定址的 instance 集合,至於需要多少 instance 則任由開發人員設定。這些 instance 沒有 request deadline,它們可以被啟動和停止(或是當呼叫到時動態啟動),它們可以使用 128M~1G 的記憶體、以及一定比例的 CPU。如果你想要了解更多,可以讀一下 Java 與 Python 版的 Backend 文件。
  • Pull Queue:現在大多數的用戶在他們的 application 中大量使用 Task Queue,不過在靈活度上還是有很許多改善空間。在 1.5.0 引入的 Pull Queue 讓開發者可以在 application 準備好時,把 task 從 queue 中「pull」出來執行,而不用倚賴 Task Queue 在先前設定好的頻率把 task push 進 queue 中。這表示你可以寫一個 Backend 來作一些背景程序,然後當 Backend 準備好時從 Pull Queue 中 pull 一個或上百個 task 來處理。此外,我們導入了 REST API,它允許外部 service 做同樣的事情。舉例來說,如果你有一個外部 server 是在做圖形轉換或 OCR,你可以用 REST API 來 pull、執行這些 task,然後回傳結果。結合這兩個改進,我們還增加了 payload 的限制與處理速度。我們很高興能同時擴展 Task Queue 的使用、以及加強改善 App Engine 與 REST of the Cloud 之間的整合。

Datastore
  • 預設為 High Replication Datastore:High Replication Datastore 經過幾個月的使用和回饋意見(以及至今 99.999% 的正常運作時間),讓我們有信心認為,這對廣大的使用者而言是正確的方向。所以,今天我們做了兩件事:當新的 application 建立時預設使用 HRD;降低 HRD 儲存的價格,從 $0.45 降低到 $0.24,來鼓勵大家開始計畫轉移至 HRD。我們一直很感謝早先使用 HRD 的使用者,他們測試、發現問題,並在這個版本當中修復其中的一些問題。

API 改變
  • 為了回應眾人的期盼,HTTP request 跟 response 的大小增加至 32MB。
  • Mail API:我們對 Mail API 增添一些限制,好讓所有使用這個 service 的 application 提高可靠性和信任度。首先,電子郵件必須以 Google 管理的電子郵件帳號(Gmail 或是 Google Apps 均可)寄出。其次,對新建立的 application,每天免費的額度從 2000 減少到 100。這些都將有助於確保 application 發出的信件可以可靠地到達目的地。

Administration
  • 下載程式碼:1.5.0 當中,除了上傳程式碼的使用者可以下載原始碼之外,也讓列在 Admin Console 的 project owner 可以下載。owner 是在 1.4.2 版引入,是一種 admin 角色。

Go
  • 新的運作環境:在 1.5.0 版當中,我們啟用一個實驗性質、給 Go 程式語言使用的運作環境。Go 是一個開放程式碼、靜態類別、編譯型的語言,但有動態、輕量級的感覺。這對 App Engine 來說也是有趣的新選擇,因為 Go 會 compile 成 native 碼;對 CPU 密集使用的 task 來說,用 Go 會是一個好選擇。截至目前為止,Go 版的 App Engine SDK 已經可供下載了,我們將儘快讓你可以 deploy Go 的 application 到 App Engine 上。如果你有興趣早一點開始「Go」,註冊就可以成為正式啟用時的首批測試者。閱讀 Go Blog 的公告,當中有更多細節。

這個版本中還有其他一海票的更改、bug 修復,所以請查閱完整的版本更新紀錄,包含所有 Java 與 Python 的議題修正。最後,如果你有興趣知道接下來這一年當中 App Engine 的方向,請到 2011 Google I/O 的其他公告看看!

2011-04-23

App Engine 1.4.3 版釋出

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


就在春天,我們提供一個新的 App Engine 版本,讓 Java 與 Python 的運作狀況更為接近。Python 方面,我們已經推出了測試的 library 來滿足現有的 Java 測試 framework;Java 方面則引入了 Deferred 與 Remote 這兩個 API。此版本還引入了一個新的 Blobstore 寫入方式、Python 版的實驗性質 Prospective Search API,以及一些 Task Queue 與 Cron 的好東西。

Python

  • Prospective Search API:實驗性質的 Prospective Search API 允許 Python 用戶在寫入符合特定條件數據時,偵測到並有所反應。在這個實驗性質的版本中,使用者可以執行 10000 次 Prospective Search API 的 subscription 。至於價錢會在完整啟用後再次公告。
  • Testbed 單元測試 framework:給 Python 使用的 Testbed 套件提供了一個簡單的 interface 讓使用 App Engine API 可以像已經存在的 Java 測試 framework 一樣整合。你不用依賴呼叫 App Engine 的 production service 就能為你的 application 建立測試,因而加速完成測試以及消除與外部 service 的相依性。在 Google 裡頭有廣為人知的測試文化,我們希望這個 API 會讓你更快地開發更穩定的程式碼。

Java

  • Concurrent Request:直到現在,Java application 仍依賴啟動額外的 instance 來動態擴展以應付更高的流量。現在,concurrent request 讓每個 application 可以同時處理多個使用者的 request。開始使用前,請先確保你的 application 程式是 threadsafe,然後在 appengine-web.xml 當中加入 來啟動 concurrent request。
  • Java Remote API 與 Deferred API:Remote API 和 Deferred API 這兩個 library 在 Python 版已經支持一段時間了,現在也可以在 Java 上頭用了!remote API 讓你可以在自己的機器上頭操作 application 的 datastore。這對於並不完全符合 App Engine 的 request/response model 的作品特別有用。Deferred API 讓使用者可以更簡單撰寫與執行 ad hoc 的 task。我們的文件當中包含了更多的資訊以及範例,告訴你如何在 Java 版的 App Engine 當中使用這兩個 API。

新的 API

  • File API:新的 File API(Python 版與 Java 版)讓你可以用程式讀寫 Blobstore 中的資料。這個 API 可以用來產生報告、匯出資料、或是任何你想要對二進位大檔所作的操作。

service 變更

  • 更新 Task Queue 與 Cron:我們已經滿足一些 Task Queue 與 Cron 上頭的優先需求。在此版本中,你可以設定 task queue 或是 cron 對特定的 application 版本發出 request。想要用像「11:00~17:00 之間每隔五分鐘(every 5 minutes from 11:00 to 17:00)」這種區間語法嗎?現在 1.4.3 版也提供啦。最後還有一點,Admin Console 的 Task Queue 頁面現在對 queue 包含超過兩千個 task 的 queue 可以顯示更精確估算 queue 的大小。

即將推出...
最後,我們要預告 1.4.4 版。在 1.4.0 當中,我們引入「讓使用者下載已經 deploy 到 App Engine 的程式碼」這個功能。1.4.2 版中,我們發表了 admin role 讓擁有者也能下載。在 1.4.4 版中,我們預計改變讓上傳程式碼的人跟(列在 Admin Console 中的) project 擁有者都能下載。 為了這個功能而作準備,一定要確保有在 Admin Console 當中妥善地對 每個開發者指定 role。或者,你仍然可以永久關閉下載程式碼這個功能。

就這些了,如果要了解更多資訊,請閱讀完整的 release note,包括 Java 版和 Python 版的所有新的功能和問題修正 。歡迎所有鼓勵與回饋的意見。

2011-02-28

發表 App Engine 的 High Replication Datastore

原文網址:http://googleappengine.blogspot.com/2011/01/announcing-high-replication-datastore.html

當 App Engine 問世兩年後,我們提供設計成快速、strongly consistent 讀取的 Datastore。它是架構在 Master/Slave 式的 replication 拓樸,設計為快速寫入、同時允許 application 可以馬上看到寫入後的資料。你可能有聽說,過去六個月我們一直在設法解決一些 App Engine 上 Datastore 的可靠性問題在過去幾個月,我們在修復這些問題方面有了重大進展。然後,處理這些問題的經驗讓我們重新思考一些設計上的假設。正如我們在年初時在 outage report 當中承諾的,我們想要更徹底地解決這個問題。

今天,我們很自豪地發表一個新的 Datastore 設定選項:High Replication Datastore。因應寫入及變更資料時 API 保證一致性所增加的延遲成本,High Replication Datastore 提供最高等級的讀寫能力。High Replication Datastore 增加了維護資料副本的 data center 數量,並使用 Paxos 演算法來讓 data center 之間的資料能立即保持一致性。其中最顯著的優點,就是在預期內的維護期間、以及大多數預期外的 infrastructure 問題上,你的 application 都會保有完整的功能。我們的文件中將更仔細的比較這兩個選項。

從現在開始,當建立一個新的 application 時,你可以選擇 Datastore 的設定。雖然目前的 Datastore 設定預設值為 Master/Slave,以後可能會改變。

建立 application 時的 Datastore 設定
Datastore 的設定選項在 applcation 建立後就不能更改,而所有已經存在的 application 都是用 Master/Slave 設定。我們提供了一些遷移工具來幫助既有 application 上的資料改使用 High Replication Datastore。首先,我們在 Admin Console 增加了一個選項,讓 application 變成唯讀模式,這樣一來資料就可以確實地在 application 之間複製。其次,我們用 Python SDK 提供了一個遷移工具,讓你將一個 application 複製到另一個去。Python 與 Java 的 application 要如何使用這個工具的文件在這裡。

現在提一下關於價格的事情:因為 High Replication 會明顯地增加資料複製量,所以價格也就會不一樣。不過,我們相信這個新的設定對於一些 application 來說會顯著改良,所以我們希望儘快的提供這個功能——即使我們還沒有決定價格的細節。因此,在 2011.07 之前,我們把 High Replication Datastore 的價格定為 Master/Slave Datastore 的三倍。七月以後,我們預計會改變這個價格。我們將會儘快讓你知道價格的詳細內容,也請記得當價格變動時,你始終被服務條款所保護。由於成本較高,我們建議 High Replication Datastore 主要是用在要有最高等級可用性的特定 application 上。

(譯註:原文最後一段懶得翻譯... [逃])

2011-02-26

App Engine SDK 1.4.2 更新版

原文網址:http://googleappengine.blogspot.com/2011/02/app-engine-142-sdk-api-updates-and.html

現在才二月,我們就已經發表今年第二次更新啦!請到這裡下載。1.4.2 版著重於改善和更新現有的幾個 App Engine API。

加強 XMPP API 讓 application 與使用者之間有更好的互動。當使用者登入、登出或作其他狀態的改變時會發出通知,且 application 可以立刻設定 presence 細節然後回傳給使用者。Subscription 跟 Presence 的通知啟用方式就像 application 設定中的 inbound 服務。

Task Queue 效能提昇與 Task Queue API 改良。首先,我們把每秒可以執行的 task 加大到 100 個。 application 也可以針對目前的 request 在個別的 queue 的設定檔當中指定最大值。這讓你可以更輕鬆地掌控 task queue 消耗了多少資源。我們還添加了一個 API,讓你以程式的方式刪除 task,而不用到 Admin Console 裡頭手動管理。

一如往常,有許多功能與議題也做了修正,例如 JAX-WS 的支援(可參見如何在 App Engine application 中建立 SOAP),當然也支援了 Django 1.2,所以請你一定要讀一下 Java 與 Python 的更新說明。我們還更新了 App Engine 的展望圖,加了一些新的專案,所以去看看吧!。如果您有任何意見想反應,歡迎到 App Engine 社群。

2010-12-12

App Engine 團隊快樂放假啦——SDK 1.4.0 釋出

原文網址:http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html

技術校正、審閱:tkcn

App Engine 1.4.0 版出來啦!這是我們本年度最重要的一個版本,裡頭包含一堆開發人員已經等很久的超棒特性:
  • Channel API — 一個雙向的 channel,無須 polling 就可以直接 pushing notification 到在 client 端運行的 JavaScript,使 server 能直接跟使用者的 browser 溝通。這個 service 使用與 Google Talk 一樣的技術,可以很輕鬆地建立即時的 application,例如多人遊戲、聊天室、或是任何協同作業為主的 application。
  • Always On—對於高優先等級、但是低流量或不定流量的 application,現在可以用 App Engine 的 Always On 功能來保留 instance。Always On 是一個進階版的功能,每個月需另外付 $9。它可以為你的 application 保留三個 instance,即使沒有任何流量也絕對不會關掉。這減緩了小流量或是變動流量的 application 在 loading request 的影響。
    App Engine 管理控制台中的 Instance 頁面,當中 Always On 是開啟的。
  • Warm Up Request—這個功能會預測是否需要更多的 instance,並且在使用者的流量傳入之前就先載入新的 instance。如此一來,就可以減少處理 request 的時間。透過 app.yaml 或是 appengine-web.xml 可以對所有 application 啟用這個功能,當 application 已經購買 Always On 也會預設開啟。一旦啟用這個功能,當 application 開始處理使用者的傳輸量前所可能要載入的新 instance 時,warm up request 就會送出。

同時,我們花了很多時間在減少或移除現存 App Engine API 的限制:

  • 拿掉背景工作的 30 秒限制—在這個版本中,我們大幅提高來自 Task Queue 跟 Cron 發出離線 request 的時間限制。現在可以執行長達 10 分鐘的程式而不會中斷。
  • 加大 API call 的大小限制—新的 API 架構讓我們可以開始取消許多 App Engine API 的 1MB 大小限制。這次已更改下列 API:
    • URLFetch 的 response 大小限制從 1MB 提升到 32MB。
    • 批次存取 Memcache 的次數也提高到 32MB。
    • Image API 的 request、response 大小限制從 1MB 提升到 32MB。

Mail API 所送出的附加檔案大小限制從 1MB 提昇到 10MB。
你可以想像,這當中的某些改變大幅度地擴展 application 的範圍,並輕鬆地用 App Engine 來完成。所以,趁熱下載 SDK 吧!

2010-03-26

App Engine SDK 1.3.2 發佈

今天,我們很高興宣佈 App Engine 1.3.2 版(Java 與 Python 版)正式發佈。1.3.2 版包含數個改變以及 bug 修正。

在這個版本當中,我們全神貫注在解除許多已經影響到開發者的限制:

  • Blobstore API—提供一個新的 method(Python 用 fetch_data,Java 用 fetchData)使你的 application 可以用程式讀取 Blob 的內容。
  • URLFetch API—你可以存取的 port 增加了。現在可以存取的 port 為 80~90、440~450、1024~65535。
  • Mail API—我們放寬了郵件附加檔案的種類,包含了常見的文件種類:.doc、.ppt、.xls。
  • Task Queue API—我們把 Task Queue 的 refill 率增加到每秒 50 次。

我們也很高興地宣佈,根據你們的回饋意見,App Engine 有了一個新的 DoS 阻斷系統。這個系統可以讓你把特定的 IP 存取你的 application 時列入黑名單當中,以防止他們浪費你的錢或是佔用你的 quota。你還可以在 Admin Console 看到最常存取你的 application 的 IP,以幫助你找出你想要阻擋的 IP。 關於這個功能的更多資訊,請參閱下列文件:Python 版、Java 版 。

這個版本還有很多改變跟修正,包含新 Java 版的 Appstat profiling tool。詳細的資料請閱讀版本更新紀錄(Python 版、Java 版),並下載新版的 SDK。