今日のつぶやき
[Twitter]今日のつぶやき ff.im/lwd57 #
#appengine で(1)version not readyが頻発, (2)何回も繰り返しデプロイ, (3)too many versionが出るようになった。versionは一つしかない。なんでだろ。 #
推測では、(1)version not readyが出ても実はデプロイできている、(2)デプロイできていないと思って何回もデプロイを繰り返すことで一日あたりのデプロイ回数のクオータを超えた。ということで一日待つことにした。 #
#appengine はデータストアの書き込みも頻繁に遅いレスポンスのものが出てきたりする。少し不安定なのかなー #
別のappidで試したところ、クライアントでversion not readyと出てもデプロイはできているみたい。 #appengine #
version not readyが出始めたらversion番号を変えてアップロードしてみてサーバ側の管理画面でデプロイの完了を確認するのがよさそう。 #appengine #
ゆれた #
#appengine のTQは頻繁にTaskが多重登録されているように見える。かなりちゃんと冪等処理しないと大変な事になりそう。 #
冪等の意味は20年ぐらい前に分散ファイルシステムを開発している時に社内ネットで教えてもらった。懐かしい。 #
新規登録の場合は、クライアントで採番したIDをレコードのIDに使用して常に上書き、削除の場合は削除対象がすでになかったらしらっと正常終了、といった解もありますね。 #
#appengine の場合、冪等を考えるとDatastoreService.allocateIdsがかなり重要。自動採番はややリスキーのような気がする。 #
UNIXがメジャーデビューして、その勢いで分散OSになるのかと思ってたんだけど、結局そうはならず、RPC、CompoundDocument、CORBAと来てJavaの分散技術も今ひとつで、(poor man's CompoundDocumentである)Webが残った。 #
今の目で考えると、分散OS的なアプローチは当時のハードウェア性能では無理で、2010年まで待つ必要があったというのが一つ。 #
当時の分散OSは、ローカルなモノリシックOSのAPIや振舞いをそのまま実現しようとしていたのだけど、これが無理だった。今のハードウェア性能でも無理なので当時はもっと無理。 #
遅延、故障の透過性を確保するのは当面無理なので、遅延、故障を織り込んだプログラミング・モデルを採用する必要がある。Web層をミドルウェアにすると、OS層や既存のミドルウェア層(e.g. SQL)とは一線を引けるので、新しいプログラミング・モデルを導入しやすい。 #
Web層の新しいプログラミング・モデルとしてはAjaxが成功例。非同期が前提なのが象徴的。 #
個人的にはREST/(HTML5|AtomPub)のレイヤーがひとつあるかなと思っています。これをWeb層と呼んでみたいかなと。これより、もう少しスペシフィックなレイヤーも必要と思います。 RT @okachimachiorz: クラウド前提の「そういったレイヤー」は… #
面白いですねー。疎結合、非同期が前提になってきそうです。 RT @nakayoshix: .@asami224 非同期といえば昨日の北大祭の「ニコニコボカロ鼎談」でも初音ミクの開発元である札幌の会社、クリプトンフューチャーメディアの伊藤社長がこんなことを仰っていましたよ。… #
表現が拙くて申し訳ありません。私のような普通のエンジニアにも身近に感じられるようになったかなというぐらいの意味です。 RT @ichiro_satoh: ハードウェアの進化によって、使えるようになった分散アルゴリズムはありますが、これまでも… #
今日の昼は山下公園Hof Brau。スパピザとチキンライス。 #
なるほど。txで解決するならずいぶん使いやすくなる。試してみよう。RT @urekat: トランザクショナルなaddでも多重はありえるのかな？ RT @najeira: 多重登録多いです RT @asami224: #appengine のTQは頻繁にTaskが多重登録... #
外出から戻ったら #appengine のTQがすごいことになってた。 #
TQ投入をtxにしたところ、今の所、多重重複投入は確認できてないけど、性能ががくっと遅くなった。どっちを取るか微妙だなぁ。 #appengine #
と、思ったらあったまって来たのかそれなりの速度で動いているみたい。これで重複が起きなくなるのなら使い得かも。経過観察中。 #appengine #
Automatically shipped by LoudTwitter