2005-02-02

mod_rewrite を使ってみる。

Prog

　Apache で、「アドレス」のURLはそのままに、内部的に処理するURLを置換するモジュール mod_rewrite 。
　たとえばはてなダイアリーだと、日付指定で http://d.hatena.ne.jp/kab_studio/20050202 とか書くけど、実際に内部の CGI なりサーブレットなりに渡される時には http://d.hatena.ne.jp/***.do?user=kab_studio&date=20050202 みたいな形式に変換して渡すことができます。でもアドレスの方は変換されてないから見る方はわからない、みたいな？
　使い方はこんな感じ。

httpd.conf の以下の行のコメントアウトを取る（つまり頭の # を取る）。
- LoadModule rewrite_module modules/mod_rewrite.so
- AddModule mod_rewrite.c
同じく httpd.conf に変換設定を追加。
- RewriteEngine on
- RewriteRule ^/nikki2/n17_01a.html$ /nikki2/n16_01a.html

　こうすれば n17_01a.html （２００５年１月前半）にアクセスすると URL はそのままに n16_01a.html （２００４年１月前半）が表示されます。
　この例はベタでスタティックな変換だけど、実際には regex 的な正規表現置換で置き換えられるんで前述のパラメーター変換ができます。
　でもさー、これってリンクの URL をサーブレット側で動的に出力するときとかもこの形式で出さなきゃいけないんだよねー、だからこの仕様をしっかり決めておかないとプログラム自体つくれないとゆー……。結構大変そう？

2005-02-02

第４話機械の魔法、機械の天使 (23) [△ ▽]

Machician

「なんか今、ぞくっと来て、悪い報せかなにかかと……」
『あ、それはゴナツ様特有のものなんです。確かに新しい魔法を授与される時ってそういう感覚ありましたね。……毎回その感じがあるというのは問題かもしれませんね……』
「あーうん、魔法が成功したんならいいや」
　ジャージはほっと胸をなで下ろす。
　本当に、シーバリウに何もなくて良かった……。
『じゃあ、次は借威魔法の方ですね』
「あ、そういえば……でも、治癒魔法だから――――へ？」
　そんな変な声を出していたのは、むしろ、シーバリウが何をしようとしていたのか、気付いていたから。
『ルィッツ！』
　左腕を右手人差し指で撫でてそう唱えると、細く赤い線が引かれた。
「…………」
『それでは、お願いします』
「って、何やってるのよ！！」
　そのスピーカーで拡声された叫び声は、シーバリウだけではなくまわりの家々や森の動物たちさえ驚かせた。
『じゃ、ジャージさん？？？』
「いくらこれから試すからって、あんたが自傷してどうするのよ！！　そんなの待ってればいつか機会あるわよ！」
『それは違います。その「機会」は本番です。そのための練習が絶対に必要です。これがその練習なんです』
「………………」
　シーバリウの言葉は正論だ。本番にいきなりやっても成功する確率は低い。
『大丈夫です。それほど痛くありませんし、治して頂けるんですから』
「それはそうだけど……さっきの魔法だって、本当に成功したかどうかわからないし」
『それは僕が保証します。ちゃんと魔法は掛かりました』
「でも……」
『じゃあ、発想の転換です。僕は今、怪我をしています。だから、治していただけませんか？』
「な――」
『僕のために（・・・・・）』
　――――――僕のために。
　それは、何気ないふとした言葉で、多分、シーバリウが意図してない意味で私に伝わっているんだと思う、そうに違いない……違いないんだから……。
　ジャージは溜息をついて。
「シーバリウ、私にそういう言い回しは効かないかないから。怪我したのあんたなんだからあんたが治せば、って話にしちゃうとこよ？」
『あ……』
　ふふ、と笑って。
「ま、今回は乗ってあげる。私はきつくはっきり言ってくれる方が嬉しいから」
『――――はい！』
「じゃ、ちょっと痛いかもしれないけど我慢しなさいねー」
　杖を振りかぶって、呪文を唱える。
『ウォーツィー！（傷よ治れ！）』

2005-02-02

体重い……。

　一度は9時半に目が覚めたんだけど、それからまた寝て11時半起き。
　寒い……体全体が重いし……。

2005-02-02

バグ直らず。

Prog

　昨日のツッコミシステムのバグ、直ってなかった（汗）。
　朝起きてからアクセスしてみたら昨日と同じ例外が……。っつーても画面的には何も変わらないんで使う分には問題ないんだけど。
　さて、どう修正するかな。とりあえずソースも落としてきて解析して、あとプールから貸し出すときにコネクションが有効かどうかチェックするようにするか……。

2005-02-02

バグの原因判明。

Prog

　Eclipse上でステップ実行して追ってみて判明。

とりあえず jar が古かった（爆）。
timeBetweenEvictionRunsMillis が 0 じゃダメ。待機状態のオブジェクトを監視するシステムって別スレッドで timeBetweenEvictionRunsMillis ミリ秒おきにチェックする仕組みになってるんで。

　あと、「最大アクティブ数」と「最大アイドル数」の違いがわからなかったんだけどソース見て納得。前者が 5 、後者が 2 とすると、同時に 5 個貸し出せるけど、そのあと返却する時にプールへと返されるのは 2 、そのあと返されそうになる残りの 3 は破棄されるんですね。頻繁に貸し出しがあるなら数字を近づけて、そうでないなら差を付けるのがいいんかな。

2005-02-02

ツッコミシステム修正。

Prog

　コネクションプールの設定を変更。

// ObjectPoolインスタンスを生成します。
// 最大コネクション数。
int MAX_ACTIVE = 100;
// コネクションプール最大時の待機時間（ 10 秒）。
int MAX_WAIT = 10 * 1000;
// コネクションプール内に保持できる未使用コネクションの数。
int MAX_IDLE = 5;
// 排除スレッドが排除処理を実行する間隔（ 0.5 秒 ）。
int TIME_BETWEEN_EVICTION_RUNS_MILLIS = 500;
// １度のオブジェクト排除処理でチェックされるオブジェクトの数。
int NUM_TESTS_PER_EVICTION_RUN = 5;
// 未使用状態でいられる時間（ 5 秒）。
int MIN_EVICTABLE_IDLE_TIME_MILLIS = 5 * 1000;
//汎用的なオブジェクトプールを作成する
GenericObjectPool pool
    = new GenericObjectPool
        ( null                    // PoolableObjectFactory （あとでセットするので null ）。
        , MAX_ACTIVE
        , GenericObjectPool.WHEN_EXHAUSTED_BLOCK
        , MAX_WAIT
        , MAX_IDLE
        , false
        , false
        , TIME_BETWEEN_EVICTION_RUNS_MILLIS
        , NUM_TESTS_PER_EVICTION_RUN
        , MIN_EVICTABLE_IDLE_TIME_MILLIS
        , false
        );

　0.5 秒間隔でチェックするように。これでちゃんと働くはず。