KayでシンプルにTaskQueueを使いこなす - When it’s ready.
AppEngineには、どんな処理も30秒以内に終わらせないとダメって言う通称30秒ルールという神の掟があってこれを破るとプロセスをKillれてしまいます。ほとんどの処理は30秒もかからないので問題ないですが、クロールとか形態素解析とかやりだすと30秒なんて一瞬です。特にネットワーク経由で複数のものを取りに行ったりすると2秒かかるのを10個もやれば、DataStoreのIOとかも含めると余裕で30秒を使いきってしまいます。 そこで、TaskQueueの登場です。適当につんどくと無料Versionだと1秒間あたり5個ずつ処理してくれます。先程の例だと、10個やるのに30秒だったのが1個処理するのに30秒使えるようになります。苦も無く10倍ゆっくりやれるわけです。 TaskQueueは、内部でキューに送れずに特定のURLに対するPOSTで積みます。引数はペイロードに入れてあげればイイらしい。今
おっと萌えキャラの悪口はそこまでだ : GAE/J TaskQueue メモ
2009年11月12日03:11 カテゴリプログラミングGAE GAE/J TaskQueue メモ GAEではTaskQueueなるものが使える。 処理をキューに積んで、アプリケーションとは非同期に処理させることが出来る。 キューはいくつか（？）用意できるので、仕事を分割して、キューに分散させて積んで並列に処理。 処理結果をMemCacheなりDatastoreなり保存して、最後にマージすることで、並列処理が出来るという寸法。 並列処理で力を発揮すると思われるTaskQueueは、排他がどうの、スケールがどうのと、 面倒なことを考えなければ簡単に使える。 TaskQueueもcronと同じようにURLを叩くだけ。アプリケーション中、任意のタイミングで、 URLとパラメータを指定してキューにaddするだけ。後はキューがパラメータ付きでURLにアクセスしてくれる。 // 静的
Google App EngineのQueueのリトライ回数取得は正確とは限らない - 2010-02-11 - きしだのはてな
Google App Engineのタスクキューでは、ヘッダーからリトライ回数が得られる。 String count = request.getHeader("X-AppEngine-TaskRetryCount"); で、この値を使ってタスクキューのリトライ回数を制限してたのだけど、その回数よりも多くリトライされることがたびたびあった。 確認してみると、リトライされてるのにTaskRetryCountの値が増えてないことがあった。 予想はしてたことだけど、あまりあてにしてはダメみたい。
TaskQueu実行の仕組み - marblejediary
ApiProxyをほげるのが面白そうなので、まずは中身をいろいろ想像してみることから始める。taskqueueメインでやっている人はあまりいなさそうなので、人の行く裏に道あり花の道、の思想で。 前の絵はApiProxyの呼び出しよりしたを中心に、こちらの11p周辺を参考に書いたものです。サービス呼び出しまでのいろんな箇所をほげっておれおれQueueみたいなものを作りたいので、今度はサービスが呼び出されるまでのところを追いかけてみました。 基本的には、datatoreなどのサービスと内部的な構造はかわらないようです。taskqueueだけ、labパッケージにきられているので特殊な構造をしているのかと思ったのですが。 DataStroeとの対比では、DataStroeService/implと言われているものがQueueFactory/Queueとそのimplで置き換えられていること、Prot
Google App Engineで長い処理をタスクキュー使って実行 - きしだのはてな
Google App Engineだと、30秒制限があって長い処理が書きにくいのですが、タスクキューは処理中に例外が発生したり30秒制限にひっかかったりすると自動的に呼び直されるので、これを使って長い処理を実行することができます。 ということは知っていたんだけど、実際どうなのかと思って試してみた。 まずこんなサーブレット書きます。 ※GAE/JはServlet3.0に対応してないので、@WebServletアノテーションは擬似コードだと思ってください。 5秒に一回QueueTestに現在値を記録するという処理を行うループを20回繰り返します。5秒×20=100秒 >> 30秒なので、確実にタイムアウトします。 タスク開始時の値をQueueLogに記録しておきます。 @WebServlet(urlPatterns="/queue/testqueue") public class TestQu
【Google App Engine】 TaskQueueは信用できないで御座候
ajn#4、面白かったで御座候。浅海先生、荒川さん、おつかれさまで御座候。今回は、TaskQueueが信用できない話をするで御座候。（ところで、御座候って書くと何かいいことあるの？） TaskQueueは必ず実行されるが正常終了するとは限らない TaskQueueはたしかに必ず起動される。例えば、"Request was aborted after waiting too long・・"というエラーになったとしても、正しく起動されるまでリトライされる。 しかし、起動してから30秒を超えた場合に、com.google.apphosting.api.DeadlineExceededExceptionやcom.google.apphosting.runtime.HardDeadlineExceededErrorが発生すると、そのTaskは強制終了となってリトライされない。※Exceptionをc
App Engine deferred for Java - hidemonのブログ
Task Queue App Engineでは，一つのサーブレットは30秒しか実行出来ない上，スレッドを使うことができない．このため普通の方法では，長時間かかるようなタスクを実行することができない．これを補う機能としてTask Queueがある． Task Queueでは，サーブレットとそれに渡す引数をタスクとして考える．このタスクをキューに積んでおくと，システムが自動的にサーブレットを引数をセットして呼び出してくれる． defered for python Task Queueは機能的には十分なのだがちょっと使いづらい． サーブレットを書かなければならない． 引数をパラメータとして与え，サーブレットの側でも取り出さなければならない． サーブレットとURLのマッピングも書かなければならない． これを解決するために，Python版では，deferredというライブラリが提供されている．これを
#AppEngine 用のアプリケーションの自動テストについて(4) - TaskQueueに関するテスト
下記のAppEngineアプリケーションの自動テストシリーズに続く、第四回目です。 AppEngine用のアプリケーションの自動テストについて(1) #AppEngine 用のアプリケーションの自動テストについて(2) - Datastoreに関するテスト #AppEngine 用のアプリケーションの自動テストについて(3) - メール送信に関するテスト Taskの「投入」をテストする TaskQueueのテストといっても「Taskの投入」をテストするのか「Taskの実行」をテストするのか、といった2種類のテスト対象が考えられます。 今回は「Taskの投入」をテストする説明をします。「WebHandlerによるTask実行」については、例えば私はテストしやすいように以下のような手法で実装しています。 何らかの機能で、Taskを投入する 投入されたTaskはWebHandler内で実行するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう