« 2006年7月 | トップページ | 2006年9月 »

2006年8月31日 (木)

システムエラーの対処法決定

【現在のSkill Attackの仕様】

・記録の更新時のファイルロックは、更新処理が終了するまで解除されない

・更新中に過負荷を与えないよう、S.A.の通常閲覧処理でもファイルロックの監視を毎回行っている(更新処理中は閲覧処理をsleepさせて、更新の終了を待つようにする)

・但し、ファイルロック開始から30秒以上が経過している場合は、ロックの解除を待たずに閲覧処理を行う(ファイルロックが30秒以上続いた場合はシステムエラー発生と考えられ、ロックの解除が期待できない。しかしながら、システムエラー時であっても出来る限りの閲覧処理は動作させるべき)

・記録の更新中に書き換わったファイルは全てテンポラリファイルとして一時保存を行っており、作成されたテンポラリファイル名は全てログ管理されている。(今までのシステムエラーは全て、このテンポラリファイルを使って復旧を行っている)



というわけで、対処法↓

「通常閲覧時のファイルロック監視において、30秒以上経過したロックを検出した場合は、テンポラリファイルとログを使って、システムエラーが発生する直前の状態までロールバック処理を開始する。全ファイルのロールバックが終了した際、ファイルロックの解除を行うことでシステムエラーから復帰とする」



今週中には機能追加します!!

| | コメント (0) | トラックバック (3)

システムエラー発生後の対応

エラーの原因は、XREAのサーバー過負荷のためにPHP処理が強制終了、でほぼ間違いないっぽいです。


現在、記録の更新処理は「ファイルロックをかける → 更新 → ファイルロック解除」の順に行っているため、更新の途中で処理が止まってしまうと、ファイルロックがかかったまま誰も更新が行えないようになっています。しかしここまで頻繁にシステムエラーが起こってしまうと、さすがに「エラーは常に起こり続けるもの」と認識した上でプログラムを組む必要がありそうです。


先日の改造で、ユーザーが記録の更新を行う時、サーバーにどのような情報を送信してきたのかを拾えるようにしたので、これを利用して「ユーザーが記録の更新情報を送信→PHP処理が強制終了→バックアップデータから、更新処理前の状態を復帰→送信された更新情報をログから拾う→全く同じ条件下で、PHP処理をもう一回行う」のような流れを作ろうと考えています。


問題は、強制終了後のどのタイミングで、PHP処理を再試行するかですね。自分が気付いてから、再試行のボタンを押すまではずっとシステムエラーのまま、とかだと自分がPCを操作できない環境に居る時にしか対応できないので、次にユーザーが記録の更新処理をしようとしたタイミング、とか一時間に一回システムエラーのチェックを行って検出したタイミング、あたりが適切なんでしょうか。

| | コメント (0) | トラックバック (3)

2006年8月20日 (日)

S.A.が時々、表示すらされなくなる理由

Skill Attackっていうか、うちのサイトの大元である http://ag2.s54.xrea.com/ 自体が、Internet Explorer で「ページが表示できません」になる事があるんですね。


で、原因はてっきり Apache の応答不良だと思っていたんですけど、それと同じと思われる状況に、 Internet Explorer ではなく携帯電話(auのOpenwaveブラウザ)で遭遇した時、予想していた 404 ではなく 502 (Bad Request)のエラーが返ってきていました。


で、サーバから 502 が返されるパターンを Google で検索したところ、どうやら「サーバの過負荷」と判断されたタイミングで発行している事も結構あるみたいです。


xrea、安いだけあってその辺りの制限は厳しかったりするのかなー。

| | コメント (0) | トラックバック (3)

2006年8月 8日 (火)

ばぐった件

昨日の19時40分~50分頃でしょうか。



Skill Attack Version 3、ていうかSkill Attack開設以来の壮大なバグが発覚。



ちょうど、⊂㌍㌢!⊃さんの名前をシステムに対応すべく JavaScript をいじったりした後だったから、何か直し間違えたかな?と思ったけど、TOP画面で出力された JavaScript のエラー文を見てみる限り、どうやら事情は違うらしく。


JavaScript で、ユーザーの名前を変数に代入しようとするところで文法ミスが出ていました。該当箇所をよく見てみると、名前を囲むためのシングルクォートがエスケープされていたのですけど、何故そのような事が起こったのかというと・・・





CGIで特定の文字(表・予・申・能など)が文字化けする
http://www.shtml.jp/mojibake/sjis_cgi.html





後方エスケープ。

DDRでは、「CAN'T STOP FALLIN' IN LOVE」等のように、名前にシングルクォートが含まれる曲が数多く存在します。それらを JavaScript で変数に代入しようとする時に、そのまま 'CAN'T STOP FALLIN' IN LOVE' のように記述すると文法エラーを起こしてしまうので、PHP側で、曲名のシングルクォートを \' に変換する必要があります。


そこで、PHPの標準関数 addslashes() を取り入れてみました。エスケープが必要な文字列をエスケープしてから返してくれるので、「じゃあ、JavaScriptで代入処理させる文字は全てこれを通せばいいんじゃない?・▽・」と思ったまでは良かったのですけど・・・


この addslashes() 関数、シングルクォートやヌル文字といった前方エスケープだけでなく、「表」「ソ」「申」「十」といった、Shift_JISの2バイト目が 0x5C の文字もしっかり後方エスケープして下さいます。


以上を踏まえて。


昨日、「ナイソ」さんが新規登録されました。


JavaScript で名前を代入するために書き出された文字列は
'ナイソ\' となるわけですが・・・



ここから先の話は、またの機会に。



ちなみにその数日前、同じ 0x5C を2バイト目に持つ「十」を名前に含んだ、「A-Y(元十字)」さんが登録を行っていたにも関わらず何も起こらなかったのは何故でしょう。


厳密には少し違いますが、大まかに説明すると以下のような理由です。

http://www.shtml.jp/mojibake/sjis_cgi.html

では、「print "私の名前は田中太\郎です。";」とすると、どう表示されるでしょうか? ここでは、「\マーク」は無視され、「私の名前は田中太郎です。」と出力されます。エスケープが必要のない文字の前に「\マーク」をつけても無視されるわけです。



最後に、今回の件で勝手に名前を挙げてしまいましたが、
ナイソさんやA-Y(元十字)さんは全く悪くないんで!

そこだけは間違いの無いようお願いします。

| | コメント (0) | トラックバック (2)

« 2006年7月 | トップページ | 2006年9月 »