v2.1 2020-01-03
・SIMリスタート時にdataserverイベントが重なった場合に発行クエリーが消失する可能性への対処
SIMリスタート直後に動作が止まってしまう可能性があると思われるため該当部分の修正をしました。特にクリティカルな不具合対処ではなく内部的(趣味的)な変更のみなので機能の追加や変更はありません。
【より詳細な解説】（LSLが読み書きできる人向けの解説）
以前からごく希にSIMリスタート直後にオンラインチェックサーバーのチェック動作が停止する見受けられ、HTTPでのアクセスには応答することから「タイマーのトリガーが失われている？」と疑念を持ち、SIMリスタート検出時にタイマーも再スタートするように細工をしていました。特にその後にSIMリスタートでの動作停止は見られなかったのですが、先日、2020-01-02(日本時間、SLだと1日)の自動リスタート直後で、またもや発現したようでスクリプトは動作しているもののチェック動作が機能していない状態となっていました。 まぁ、単純にスクリプトリセットすればOkay♪なのですが、拘りのMH+ Labですから、原因究明すべく再度見直してみることにしました。このガジェット以外はどれも正常に動作していることからタイマー動作が偶発的に停止してしまうという考えが偶発的に発現するなら他の動作中のタイマー類でも同様の事象が起こるはずですから、どうやら見当違いだったのではとの答えに至りました。だとしたら、このオンラインチェックサーバー特有のロジックに原因があるのではとじっくりと見てみたところ、「もしかしたらデータサーバーへのリクエスト処理途中で途切れて（リスタートして）しまったのでは？」と思うようになりました。確認する術がないので確証はありませんが、そうだとしたら動作が停止する構造になっている箇所があると発見しました。
何を言っているか具体的に良く分からないと思うので、かいつまんで説明すると
スクリプトの一連の流れで
１．タイマー停止(Keyが初期状態なら)
２． →データリクエストクエリ発行(クエリーKeyセット)
３． →データサーバーからの返却(イベント待ち)
４． →クエリーKeyと等しい結果受信
５． →クエリーKey初期化
６．タイマー再開
この１～６の流れをチェック対象のUUIDの数の分だけループ処理するのですが、この流れで３と４の間でSIMリスタートが発動した場合、リクエストしたクエリーが消失しているのではないかという疑念です。
あ、DoやForでのループでなく、タイマーで回しているのは、処理数に単位時間当たりの使用制限がある処理を、制限を超えないように使うためです。
Alive-Cサーバー群のようにHTTPを利用した物だと、そもそもHTTPの応答は無応答の場合を想定して自前で処理しなければならないため特に問題にならないのですが、LSLのデータサーバを使う前提の処理で、リクエストに無応答というパターンがあるのではないか？という、あくまでも想像ですけど、そんな気がしてなりません。少なくともMH+オンラインチェックサーバーのロジックではSIMリスタートの契機でタイマーも強制で再始動を掛けていました、しかし動作が継続していないことからデータサーバーからの返却が無く、キーを初期化する契機が発生しなかった為に、ずっと待ち状態となっていたと考えています。（キーが空の時に次の処理を行う判断としているため）
この問題が発現したのは MH+オンラインチェックサーバー だけですが、頻度が少ないとはいえ同様のロジックが一部存在する MH+据置型RezDay備忘録サーバー も修正対象としました。
0 件のコメント:
コメントを投稿