過去の桐井戸端ＢＢＳ　（桐ver.８）
8684 桐でイントラネット「kiri-cgi」で検索ができなくなる場合がある みすず 2000/11/20-11:15
セミナーで配ったkiri-cgiで、何らかの原因でlock.txtが残ってしまい検索ができなくなる場合があります。
たとえば、ブラウザのHTTPアドレスに直接kiri-cgi.exeを指定された場合などです。
そのような状態に陥った場合、どのようにしてlock.txtを削除して元に戻せばいいんでしょうか？

8685 Re:桐でイントラネット「kiri-cgi」で教えてください。 hidetake 2000/11/20-11:50
記事番号8684へのコメント
待ち受けている「桐」の一括処理側でlock ファイルのタイムスタンプを見て一定時間でタイムアウト処理を行い
強制的に lock ファイルを削除すると言う方法になると思います。

「桐」の一括処理が待ち受けて無くて、reply.htm が帰ってこない場合とか、
IIS が 15分間で KIRI-CGI.EXE をタイムアウト処理し強制終了させるようです。
当然、この場合も lockファイルは残されるので、「桐」の待ち受け側も、
起動時に不要なファイルの削除も付け加えなくてはならないと思います。

8686 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/20-13:14
記事番号8685へのコメント
タイムアウトをもうけて、時間によって削除すれば良いわけですね。
連続的に使えなくなるとまずいので、タイムアウト時間を１分程度で実用化は可能でしょうか？

8687 Re:桐でイントラネット「kiri-cgi」で教えてください。 hidetake 2000/11/20-13:25
記事番号8686へのコメント
>連続的に使えなくなるとまずいので、タイムアウト時間を１分程度
>で実用化は可能でしょうか？

う〜む、いくらが適正なのかはわかりませんが、１分もして戻ってこないようだったら、正常とは思えないでしょうね！

普通の CGI のロック処理でもタイムアウト処理は分単位だとは思いますが、
あとはサーバ側のレスポンスの問題などを考慮しながら試行錯誤でしょうか？

8688 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/20-13:45
記事番号8687へのコメント
どうもありがとうございます
色々試して適正な時間を調べてみることにします。

8689 Re:桐でイントラネット「kiri-cgi」で教えてください。 hidetake 2000/11/20-13:55
記事番号8688へのコメント
本題とは関係ありませんが、KIRI-CGI.EXE が動作(待機)している時の CPU 使用率って非常に高くありませんか？
それに比べ、桐側の待機状態はホンの微々たるものです。

KIRI-CGI.EXE や KIRI-MAIL.EXE が試用している Cygwin(CYGWIN1.DLL) 自体が、UNiX MAGAZINE によると
http://www.ascii.co.jp/books/magazines/unixmag/
遅いとか不安定とかの要因を持っているそうですね・・・
それに KIRI-CGI.EXE や KIRI-MAIL.EXE のライセンスも
どうも良くわからない？

いろいろ工夫は必要なようです！

8691 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/20-15:52
記事番号8689へのコメント
Cygwinっていうのを使っていたんですね。
初めてしりました。
kiri-cgiがカスタマイズできれば本当はうれしいんですけど、
Delphiあたりで同種の物が作れれば、と現在模索中です。

ところで監視一括処理の件で
ついでにご質問ですが、サンプルでは検索元の表と、CGIの結果を格納するCGI.TBLを常に開きっぱなしにして、
ループ待機状態になってますが、
REQ.TXTを発見した時点でファイルをオープンし、
検索終了したら即ファイルを閉じるような処理の方が安全だと思うのですが、いかがでしょうか？

また、サンプルは「ファイル入力開始」を試して、終了状態オプションででREQ.TXTの生成を監視していますが、
「#ファイル検索」関数でREQ.TXTを監視し、ファイルを発見したら「ファイル入力開始」を行うようにしたほうが
良いように思えますがいかがでしょうか？

8692 Re:桐でイントラネット「kiri-cgi」で教えてください。 hidetake 2000/11/20-17:14
記事番号8691へのコメント
>Delphiあたりで同種の物が作れれば、と現在模索中です。

CGI を DLL や EXE で作ったからと言って、本当に速くなるのか、
なんて問題は、いろいろあって一概に言えないようです。
汎用性を考えるなら Perl による CGI で作っておいたら、
Webサーバを選ぶこともなく、変更も楽でしょう！
Linux とかで mod_perl しても良いでしょうし・・・


>ついでにご質問ですが、サンプルでは検索元の表と、CGIの結果
>を格納するCGI.TBLを常に開きっぱなしにして、ループ待機状態
>になってますが、REQ.TXTを発見した時点でファイルをオープン
>し、検索終了したら即ファイルを閉じるような処理の方が安全だ
>と思うのですが、いかがでしょうか？

この辺も目的やアクセスの頻度などによるのでは無いでしょうか？
ファイルをその度に開くというのは、レスポンスの問題を考えると不利でしょうし、
勝手に他人に開かれたいたりする場合の事も
考えておいたりすると入らぬ心配で面倒ですし・・・
だいたいサンプルでは専有で開いているので、他の人は一切データを参照したり、更新できないですよね！


>また、サンプルは「ファイル入力開始」を試して、終了状態オプ
>ションででREQ.TXTの生成を監視していますが、「#ファイル検索」
>関数でREQ.TXTを監視し、ファイルを発見したら「ファイル入力開
>始」を行うようにしたほうが良いように思えますがいかがでしょう
>か？

この辺もいろいろあって良いのでは無いでしょうか？

参照系でしか使わないのなら、桐側では適当に、外部DB でデータを書きだしておいて、
ODBC 経由の IIS + ASP や　Apache + PHPとか、いろいろな方法もあると思います。


この K3 が提供したサンプルも、あくまで完成品ではなく試作品であり、
情報提供であり、実際に使うにはいろいろ工夫や試行錯誤が必要なようです。


8694 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/20-17:38
記事番号8692へのコメント
なるほど。大変勉強になりました。
どうもありがとうございます。

8704 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/21-10:47
記事番号8689へのコメント
>本題とは関係ありませんが、KIRI-CGI.EXE が動作(待機)
>している時の CPU 使用率って非常に高くありませんか？
>それに比べ、桐側の待機状態はホンの微々たるものです。

たしかに動作しはじめると異様なまでの重さにサーバシステム全体がなってしまいますねー
はじめはサーバがいかれたとおもいました。

8705 Re:桐でイントラネット「kiri-cgi」で教えてください。 hidetake 2000/11/21-11:32
記事番号8704へのコメント
NT の CPU の使用率はタスクマネージャ(TASKMGR.EXE) で、
PC 全体、CPU 単位、プロセス単位に確認できます。
デスクトップからだと、タスクバー上で右クリックして起動できます。

さて、例えば「桐」側の待ち受けがされていない状態、あるいは reply.htm が帰ってくるまでの間(これですと短い時間)
で、kiri-cgi.exe は CPU をほとんど使い尽くしている状態になると思います。

私の環境では Dual CPU な NT で確認しましたが、kiri-cgi.exeが１つ動いて(待機して)いる状態で、
システム全体で 52 &程度の CPU 使用率になります。
片方の CPU がほとんど 100%の状態です。プロセス単位で見ると 45〜48% 程度でしょうか

この状態で lock ファイルを手動などで削除し、次の kiri-cgi.exeが起動されたら、システム全体で 92% 程度にまで跳ね上がり、
kiri-cgi.exe の２つのプロセスが、それぞれ CPU をほぼ使い切った状態になります。
シングルプロセッサでは１つの kiri-cgi.exe だけで完全に100% 近くの資源を使ってしまうのでは無いでしょうか？

この状態は IIS が kiri-cgi.exe をタイムアウトで解放する15分間続くわけです。（あるいは reply.htm が返るまで）

まぁ〜、正常に稼働している状態では、ほとんどストレス無しに reply.htm は返され、
それを見て処理したら kiri-cgi.exeも終了しプロセスから解放されるので CPU の使用率はそんな
にあがるわけでもありませんが、桐側のレスポンスや、待機されていない状態など、
あるいは負荷の高いシステムが必要な場合は注意しておく必要があるかも知れません。

ps.
kiri-mail.exe も CYGWIN1.DLL を使っている関係で、
似たような症状になりそうな気もしますが、さすがにそこまでは調べておりません。
まぁ〜、こちらはクライアントで実行できるし、通常の使い方はそれが普通でしょうし・・・


8715 Re:桐でイントラネット「kiri-cgi」で教えてください。 みすず 2000/11/22-09:46
記事番号8691へのコメント
>また、サンプルは「ファイル入力開始」を試して、終了状態オプ
>ションででREQ.TXTの生成を監視していますが、「#ファイル検索」
>関数でREQ.TXTを監視し、ファイルを発見したら「ファイル入力開
>始」を行うようにしたほうが良いように思えますがいかがでしょう
>か？

自己レスです。
後日談ですが、この手法は無理でした。（というより無意味？）
#ファイル検索で発見した時点で処理を開始すると
req.txtが生成途中のため、正確に読み込めないようです。
#ファイル検索だと存在確認しか出来ないためだと思われます。
やはり、ファイル入力開始で一度試しにファイルオープンしてみて、
存在確認＆共有確認を行った後で処理を開始しないとダメでした。


戻る