GAE/J のHeapサイズの上限を実際に測ってみたくて、実験してみた。 実験プログラム プログラムは、以下のようなサーブレットを作っただけ。 private static byte[][] data = new byte[100][]; private static int count = 0; public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { // set content type resp.setContentType("text/plain"); // show memory usage resp.getWriter().printf("maxMemory = %12s\n", new DecimalFormat().format(Runtime.getR

パスタ習作#2 飽き性な性格なのに#1を書いた以降も意外とパスタ熱が冷めなかった。当たり前のことだが、基本が分かってくると応用ができる。応用ができると自由度が増す。自由を手に入れると継続ができる。批評家の福尾匠が自身の日記に、小倉知巳のペペロンチーノのレシピはよくで…

GoogleDocsとGAEの連携 GoogleDocsやGoogleAppsとGAEは相性がよく、これらを組み合わせたアプリを作りたいと考えている方も多いだろう。私もこの組み合わせは気に入っていて、下図のような、Google Apps 3層アーキテクチャーを基本にしたマッシュアップアプリが作れないか日々、研究している。 この記事を書いてるあいだに、タイムリーにグーグル、Google Apps向けマーケットを開設なんて発表があった。今、Google Apps連携が熱い。 Google Docsについては、先日、すごいのはGDriveより全文検索でしょ！？にも書いたが、PDFやEXCELといった様々なタイプのコンテンツをほぼ無制限に格納でき、かつ全文検索もできるので大変便利である。Google Docs List APIのAnyType Uploadなどは、Google AppsのPremi

ハリイカの焼売と中華炒め ハリイカをよく、見かけるようになりましたよ。生け簀で、泳いでいたものを一杯購入しました 立派な大きな墨袋や肝は冷凍保存して 柔らかな身は季節のお豆、お野菜と合わせて中華の炒めものに。新鮮なにんにくの茎は刻み、香り高く食欲そそられますね 下足はミンチにし…

App Engineの英語MLちゃんと読んでますか？　私は読んでません！(ｷﾘｯ 量多すぎます！ そこで初めてYahoo Pipesなるものをいじって、「3つのApp Engine MLからフィードを取得して、Googlerが書いた記事（送信者メアドにgoogle.comが含まれるもの）だけ取得するRSSフィード」というものをつくってみました： Google App Engine ML / Googler's answers これ、なかなか調子いいですよ！まあ最近は大抵Ikaiさん（←なんて読むの？）がレスしてますが、ちょくちょくNickさんも答えてますね。このフィードの元フィードは以下の3つです。 Google App Engine Google App Engine for Python Google App Engine for Java ご存じのとおりApp Engine開発者は何

ひがさんの発言で「slim3:1100cpu_ms servlet:720cpu_ms 」ってのがあって、自分のアプリではslim3は大体700-1100cpu_msだったから気になって調べた。 同じApplicationIDで、それぞれ違うバージョンにデプロイし、クライアントから3分おきにcurlしてみた。結果、どちらもspinupは11回、しかも同じタイミングで発生。バージョンが異なれば違うアプリケーションとして動作するけど、同じタイミングでspinupしてるのは偶然…？それは置いといて、肝心のspinup平均はslim3が960cpu_ms, 素Javaが694cpu_msとなった。なんか遅いよな？とか思ったけど、700ms程度で起動しているアプリも今は900ms程度に落ち着いていた。というわけで、slim3と素Javaのspinup時間差はおよそ250-300cpu_ms程度と見れ

先日セッションデータを消したかったのは、Datastore使用量が1GBを超えて一日0.01$の課金がかかってたからなのです。日曜日くらいに無事消えました。 Google App Engine/Javaでセッション情報を定期的に消す処理 130万件を消す処理に5日以上かかった計算に。もちろん、もう少しちゃんと組めばもっと早く終わると思うのですが、それはつまり、130万件を消去する処理を書くには単純なコードでは無理ということです。※急いでなかったので30分に13回程度の処理しか行ったためで、ちゃんと処理をすると3時間かからないくらいにはなりそうです。(23:08追記) まあ、日数がかかるのはいいとして。 セッション情報がたまってるときのエンティティサイズはこのように360MB程度になっていました。 ただ、このときデータストア使用量は1GBを超えて、0.01$の課金がかかっています。 これが、

さて、ajn5が終わりブログに感想も書かず何をしていたかというと、松尾さんのプレゼンで見たappstatsをパクっていました。結構前からやはり松尾さんのつぶやきで存在は知っていたのですが、いろんな事情で手が付けられない感じでした。 とはいえ、@bufferings氏や@ashigeru氏のpushと倍pushを受けて、これは土日にやらねばならぬとして簡単にですがものをつくってみました。もちろん、どの土日かは宣言していないので、「つまり・・・・我々がその気になれば・・・リリースは　10年後　20年後ということも、可能だろう・・・・・・・・・・ということ・・・・！ 」です。 まぁ常識の範囲ということで、デモが動くようにしています。見切りでリリースしてもいいのですが、それはfairでない気もするので。 説明が遅れましたがいちおうappengineに詳しくない人向けにappstatsについて簡単に

でた．プレリリースが先週出ていて，その1週間後に予定通り本リリース．データストア周りが結構変わっていて，これまで苦労していた部分で苦労しなくて済みそうな感じ． Query Cursor いわゆるカーソルが導入された．RDBだと普通にあるのだけど，データストアからの読み出しにrangeで制約をつけておき，結果からカーソルを取得しておくと，次に同じキュエリをだすときに，カーソルを指定して，そのつづきから，という形で検索ができる． これまでだと，ソートのキーになっているプロパティの値を取っておいて，それを条件に加えて検索していたのだけど，そんなテクは不要に． No more 1000 result limit これまで，データストアには，1000個以上の値を返せない，という結構きつい縛りがあった．rangeで指定しても，たとえば 900-1100 みたいな検索ができなかった．この制約が無くなった

Google App Engine for Java上のWEBアプリでPDFを出力しようと思ったのだが、 色々問題が出てきた。 ･iText 5 JavaでPDFを出力する、という話になったときまず出てくるのがiTextだが、 最新版であるiText 5.x系統はライセンスがAGPL。 ･iText 2 前バージョンであるiText 2.x系統だとライセンスはMPL/LGPLのデュアルライセンス。 しかしGAE/Jのブラックリストに載っているAPIを使っているので動かない。 ･Apache FOP これもGAE/Jのブラックリストに載っているAPIを使っているので動かない。 といったところで困っていたのだが、 森薫さんという方がiText 2.1.7をGAE/Jで動くようにModifyしてくれていた。感謝です。 http://d.hatena.ne.jp/kaorumori/2009082

Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi