ここの掲示板の検索についてです。「全ログのワード検索」というところね。
普通にブラウザで検索すると、なんて事なく検索できます。
その検索結果のＵＲＬを、別のブラウザのＵＲＬ窓に直接入力しても同じ結果が
得られます。当り前ですかね。

ところが、私の自作ツールでそのＵＲＬを指定しても、結果を得る事ができませ
ん。Lock is Busyとかなんとか、そんなメッセージが出てきてしまいます。でも、
検索以外のところはリスト表示でも新着記事でも個別発言表示でも私のツールで
うまく結果を取得できています。

もしかして、スパム投稿対策かなにかで引っかかっているのでしょうか。でも、
POST ではなく GET の部分ですからあまりスパム対策には関係ないような気もし
ますし、よくわかりません。
もし差し支えなければ、検索の場合で上記のメッセージが表示されるのはどのよ
うな場合か、ご教示いただけないでしょうか。スパム対応の関係で開示できない
という事であれば、その旨を一言いただけるだけでも結構です。

なにとぞよろしくお願いします。

> ところが、私の自作ツールでそのＵＲＬを指定しても、結果を得る事ができませ
> ん。Lock is Busyとかなんとか、そんなメッセージが出てきてしまいます。でも、
> 検索以外のところはリスト表示でも新着記事でも個別発言表示でも私のツールで
> うまく結果を取得できています。

う〜む、メッセージからすると、時間が掛かりすぎてタイムアウトにでもなっている
ように感じます。全ログ検索なので、ツリー表示の何倍も掛かっているはずなので。
それに、さいきんはhpcgi3.nifty.comの負荷が重くて、サーバーエラーが頻発して
いるので、その影響もありそうです。検索にスパム対策はしてません。

> う〜む、メッセージからすると、時間が掛かりすぎてタイムアウトにでもなっている
> ように感じます。全ログ検索なので、ツリー表示の何倍も掛かっているはずなので。

メッセージを出力しているのは、サーバのデーモンではありません。
CGIのスクリプトです。具体的には、LOCK機構の部分です。
スクリプト内部を検索すれば、すぐにわかりますよね。

LOCK機構というのは、本来、２つ以上の投稿が競合した時にログが破損すること
を防止するためのものです。ところが、wforumのスクリプトでは、検索時にサー
バに負荷がかかるため、二重検索が禁止されており、この目的でもLOCK機構が使
われています。つまり、検索しようとすると、まず真っ先に現在ロックされてい
るかどうかを確認し、ロックされていなければロックして検索開始ですが、ロッ
クされていれば私の見たメッセージが表示されるというしくみになっているわけ
です。すなわち、検索が始まる前にこのメッセージをくらっているのですから、
タイムアウトというのはありえないはずです。

私に考えられる可能性は２つ。
LOCK機構は投稿の際と同じものを共用していますので、私が検索しようとした時
に、たまたま誰かの投稿と競合してしまった、というもの。ただ、気がついたの
は数週間前ですが、それ以降、数十回とは言わずとも、少なくとも十数回は自作
ツールで実験していて、それが全て競合してしまうというのは、いくらスパム投
稿が多くても、あまりありえそうな話とは思えません。それに、ブラウザからは
全く競合しないというのも不思議な話です。
もう一つは、スパムチェックの関係にLOCK機構も使われているのではないか、と
いう事。上記のとおり、本来は投稿用のルーチンを検索時にも流用しているわけ
ですから、この部分にも何か改造が入った可能性があるかな、と妄想したわけで
す。でも、konnoさんに「検索にスパム対策はしてません」と明言されてしまった
わけですし、私自身、LOCKルーチンをどう改造すればスパム対策になるのか見当
もつかないという事もあって、こちらの可能性も低そうですね。

ということで、まったくもって不思議な話ではあります。


> それに、さいきんはhpcgi3.nifty.comの負荷が重くて、サーバーエラーが頻発して

上記のとおり、これは本件には直接は関係ないはずですが。
でも、ほんと、最近はサーバーエラーが多いですね。
それだけ、サーバー全体としてアタックが多いという事なんでしょうけど。

> メッセージを出力しているのは、サーバのデーモンではありません。
> CGIのスクリプトです。具体的には、LOCK機構の部分です。

あ、そうだったんですか。てっきりとしきさんのツールのメッセージかと。(^^;
で、見当も付かないのですが、ロックのルーチンは5回リトライして駄目ならエラー
としているようなので、サーバーの負荷が高すぎると、その5回の間に反応しきれて
いないんではないかと疑ってみました。そこで、5回から30回に増やしてみました。
これでどうでしょうか。

> でも、ほんと、最近はサーバーエラーが多いですね。
> それだけ、サーバー全体としてアタックが多いという事なんでしょうけど。

私もそう思いますが、CGIの無限ループとか多用しすぎでもサーバーの負荷が上がる
そうなので、もしかしてうちのCGIが原因だったりして。(^^;

> いないんではないかと疑ってみました。そこで、5回から30回に増やしてみました。

残念ながら、効果はありませんでした。
「LOCK 1 is BUSY」みたいなメッセージが出てしまいました。

そこで、基本に立ち返って、私の自作ツールが悪いという線で、もう一度ソース
を洗い直して見ました。すると、怪しげな部分が１ヵ所、見つかりました。
このツール、まずHTTPのHEADメソッドを投げて、きちんと情報が取得できたら、
即座にGETメソッドを投げて実体を取得する、という構造になっていました。とこ
ろが、サーバ側の条件によっては、HEADメソッドを受け取ってもGETメソッドを受
け取ったのと同じ動作が走るのです。すなわち、今回の場合、HEADメソッドを受
けて検索が始まり、全ログ検索に時間がかかって処理が終わらないうちに、今度
はGETメソッドを受けてしまうので二重検索という事でこのメッセージをくらって
しまったようです。
なので、今回の場合は私のツールとここのスクリプトのそれぞれの仕様の組み合
わせの問題ということが判明しました。いわば相性といえるのかもしれないので
すが、どちらが悪いというものでもありませんので、これ以上の対応はあきらめ
ることとしました。konnoさんにもお手数をおかけして申し訳ありませんでした。


> > でも、ほんと、最近はサーバーエラーが多いですね。
> > それだけ、サーバー全体としてアタックが多いという事なんでしょうけど。

余談。
昨夜２２時過ぎ、うちのサーバにイギリスから猛烈なアタックがありました。
ほんの十数分の間に、６００回以上の読込と２００回以上の書き込み。
うち、検索エンジンやらスパマーやらのアクセスを全部ひっくるめても、平均す
ると１日あたり３００回ぐらいの読込と５回未満の書き込みしかないわけですか
ら、これがいかに猛烈なものだったかがわかります。よくサーバが落ちずに保っ
たものだ。(^^;
昨夜は宿直だったもので、こんなことになっているとは露知らず。今日、帰宅後
にログ監査してびっくり。さっくりとアクセス規制実施。とりあえず、一つも書
き込ませずに済んだからよかったけど、全部書き込まれていたら一体どんなこと
になっていたやら。

> 残念ながら、効果はありませんでした。
> 「LOCK 1 is BUSY」みたいなメッセージが出てしまいました。

だめでしたか、残念。

> はGETメソッドを受けてしまうので二重検索という事でこのメッセージをくらって
> しまったようです。

よくわかってないんですが、このGETを1回だけで済ませられないもんでしょうか。
しろうとがとんでもないことを言っているような気はしてますが。(^^;;

> 昨夜２２時過ぎ、うちのサーバにイギリスから猛烈なアタックがありました。
> ほんの十数分の間に、６００回以上の読込と２００回以上の書き込み。

ひゃあ〜、やはり最近はどこのサーバーにもアタックが多いんですねぇ。
嫌な世の中になってきました。

> よくわかってないんですが、このGETを1回だけで済ませられないもんでしょうか。

ある目的で作ったツールを全然違う目的に流用していたのです。
そして、元々の目的のためには、GETを１回というわけにはいかないのです。
だけど、手持ちのコマは潤沢とは言わないまでも複数あるもので、GETを１回しか
送出しないツールを発掘し、そちらを使うことで、何とか不具合を回避すること
に成功しました。

ありがとうございました。

> だけど、手持ちのコマは潤沢とは言わないまでも複数あるもので、GETを１回しか
> 送出しないツールを発掘し、そちらを使うことで、何とか不具合を回避すること
> に成功しました。

おお、さすがとしきさん。引き出しを一杯持ってるんですね。
できればどうやってるのか、ちょこっと解説してくれるとうれしいなぁ。(^^;

> できればどうやってるのか、ちょこっと解説してくれるとうれしいなぁ。(^^;

多分、誰の役にも立たないことは明白なので、解説などという手間のかかること
はしたくなかったりします。うちの板塀の#1179から始まるツリーに関連したこと
なんですが。

私がDOSでWEBアクセスするために使っているソフトのLOUKがHTTP/1.1に対応して
いない、というのがそもそもの端緒。一方で、hpcgiをはじめ、最近は多くのサー
バがHTTP/1.1に移行してしまっているという現実があります。ではどうするか。
プロキシを使う、というのが一つの答ですが、残念ながらLOUKはプロキシにも対
応していません。なので、自宅サーバをプロキシもどきに使うことにしました。
ところが、そのために使っていたのがfake proxyという自作ソフトですが、これ
がHEADとGETの二重アクセスを行うようなロジックになっています。二重アクセス
しないで済むように改造することは不可能ではないと思うのですが、製作時の私
の技術力では、仕様を満足させるためには二重アクセスするしかなかったのです
ね。つまり、このツールを改造するのが筋だけど、現在はちょっと気合いと根性
が足りない。それらが充足して改造に着手すると、今度は技術力が足りないこと
が発覚するのかもしれませんが、それはさておき。

やってることは、CGIにパラメータとしてURLを渡すと、CGIの応答としてそのURL
のファイルを返してくれる、というものです。こんなものは、実行ファイルとし
て作らなくても、perlのスクリプトで十分実現可能。それこそ、HTTPでのファイ
ル取得結果を標準出力にそのまま流してくれるソフトさえあればperlも不要。そ
ういえばそんなソフトを作った記憶もある。
でも、ファイル本体だけ返してもらってもうまく行かない。HTTPのヘッダをつけ
る必要がある。これをきちんと偽造するためにfake proxyは二重アクセスしてい
るのですから。だけど、汎用性を狙うのでなく、決めうちのダミーなヘッダで良
いのなら、バッチファイルで構成することも可能。なら、ちょっとバッチファイ
ルを組んでみようか、ということででっちあげてみたら、見事に成功。

linuxなWEBサーバがあれば、wgetとシェルスクリプトで構成するところでしょう。
うちはたまたまWindowsサーバなので、自作のソフトを組み込むということになり
ましたが。

> 多分、誰の役にも立たないことは明白なので、解説などという手間のかかること
> はしたくなかったりします。うちの板塀の#1179から始まるツリーに関連したこと
> なんですが。

なるほど、HTTPの仕様も古い形式はもう使えなくなってるわけですね。といっても
お仕着せのブラウザを使用している限りはその変化にさえ気が付かなかったですが。

> やってることは、CGIにパラメータとしてURLを渡すと、CGIの応答としてそのURL
> のファイルを返してくれる、というものです。こんなものは、実行ファイルとし
> て作らなくても、perlのスクリプトで十分実現可能。

なるほど、perlのCGIでも出来るなら、いつか私もやってみたいですね。

> いのなら、バッチファイルで構成することも可能。なら、ちょっとバッチファイ
> ルを組んでみようか、ということででっちあげてみたら、見事に成功。

げげ、BAT ですか。ということは自作ツールとの組み合わせですね。色々HTTP関係の
ツールを作成されてたようだし。それを使いこなすには、やはりいろいろ勉強する
必要がありそうですね。これもいつか、そのうちに。(^^;

> なるほど、HTTPの仕様も古い形式はもう使えなくなってるわけですね。といっても

使えなくなりつつある、というのが現状ですね。
まだまだ、古い仕様でアクセスできるところは多いというか、サイト数ベースで
は古いままのところの方が多いような気もします。総アクセス数ベースでは新し
い方が過半数でしょうが。

> なるほど、perlのCGIでも出来るなら、いつか私もやってみたいですね。

perlでやるなら、ソケットにアクセスするための機能が必要になります。
ただ、残念ながら、ニフティのCGIのperlでは、この機能が潰してあります。
多分、この機能を迂闊に開放すると、スパム発信元として利用されてしまうから
でしょう。
でも、自分の手元のマシンでやるなら、何でも可能。
perlってインタプリタ言語だし、すぐにエラーメッセージを出してくれるから、
コマンドラインで動く何かを簡単に作ろうと思ったら、C++でコンパイルしてあれ
やこれやするよりもずっと楽なような気がします。