俳優のフレームワークが「ブラックボックス」に変わると、それに対して何ができるでしょうか？

アクターモデルは、ある種の問題を解決するための優れたアプローチです。 特にC ++言語の場合、既製のアクターフレームワークは、開発者の生活を大幅に簡素化できます。 プログラマは、作業コンテキストの管理、メッセージキューの整理、メッセージの有効期間の監視などのかなりの心配から解放されます。 しかし、彼らが言うように、 この人生で良いことはすべて違法であるか、不道徳であるか、または肥満につながります。 既製の（つまり、他の誰かの）アクターフレームワークを使用する場合の問題の1つは、それが「ブラックボックス」に変わることがあるということです。 この「ブラックボックス」に与えたものが表示され、そこから得られるものが表示されます（もしあれば）。 しかし、最初のものから2番目のものがどのように取得されるかは常に明確ではありません...

何言ってるの？

SObjectizerフレームワークの使用時に開発者が遭遇する最も一般的な問題の1つは、送信されたメッセージを受信しないことです。 つまり メッセージは送信されましたが、受信者には届きませんでした。 なんで？ しかし、これは興味深い質問です。



送信されたメッセージが受信者に届かない主な理由はいくつかあります。



1.受信者は存在しません。 すでに存在しないか、存在しないことは重要ではありません。 レシーバーは、sendを呼び出すときに存在する可能性がありますが、sendが作業を完了する前でも存在しなくなる可能性があります。 または、sendを呼び出すことにより、レシーバーは既に存在していると考えられますが、実際にはまだ作成されていません。



2.受信者がメッセージを購読しませんでした。 それは特定のメッセージとすべてを購読するのを愚かに忘れていました。 メッセージが送信されると、必要なエージェントにも配信されません。 彼は単にメッセージを購読していません。 または、オプションとして、誤って受信者を別のメールボックスからのメッセージに署名しました。



3.受信者が目的の状態のメッセージを購読していません。 たとえば、エージェントは、メッセージを処理したい3つの状態があることがわかりました。 しかし、サブスクリプションは2つの州に対してのみ行われましたが、3番目の州については忘れていました。 メッセージが到着したときに受信エージェントがこの3番目の状態にある場合、メッセージは受信者に配信されません。



他の理由もありますが、これらは最も一般的です。



私たちの観察によると、No。2とNo. 3の理由が最も一般的です。 そして、SObjectizerの初心者と経験豊富なユーザーの両方がこのレーキを攻撃しています。 SObjectizerの開発者である私たち自身でさえ、これらの愚かな間違いを定期的に犯します。 これはどうですか？ はい、非常に簡単です。

サブスクリプションが正しくない単純な例

以下に、Pingerとpongerのエージェントが共通のマルチプロデューサー/マルチコンシューマメールボックスを介してpingおよびpong信号を交換する簡単な例のコードを示します。

#include <so_5/all.hpp> // ,    pinger  ponger. struct ping final : public so_5::signal_t {}; struct pong final : public so_5::signal_t {}; //  pinger,   ping,   ping    pong. class pinger final : public so_5::agent_t { //  ,      . const so_5::mbox_t mbox_; public: //       . pinger(context_t ctx, so_5::mbox_t mbox) : so_5::agent_t{std::move(ctx)} , mbox_{std::move(mbox)} { //      . so_subscribe(mbox_).event([this](mhood_t<pong>) { std::cout << "pong!" << std::endl; so_5::send<ping>(mbox_); }); } //         ping. virtual void so_evt_start() override { so_5::send<ping>(mbox_); } }; //  ponger,   pong-    ping-. class ponger final : public so_5::agent_t { //  ,      . const so_5::mbox_t mbox_; public: //       . ponger(context_t ctx, so_5::mbox_t mbox) : so_5::agent_t{std::move(ctx)} , mbox_{std::move(mbox)} { //      . so_subscribe_self().event([this](mhood_t<ping>) { std::cout << "ping!" << std::endl; so_5::send<pong>(mbox_); }); } }; int main() { //  SObjectizer       . so_5::launch([](so_5::environment_t & env) { env.introduce_coop([](so_5::coop_t & coop) { //  ,   . const auto mbox = coop.environment().create_mbox(); //  . coop.make_agent<pinger>(mbox); coop.make_agent<ponger>(mbox); }); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この単純なコードには小さなエラーがあります。これは、例を実行するときにping / pongメッセージの印刷が表示されないためです。 おそらく誰かがすでに何が起こっているのか理解していたのでしょう。 しかし、一般的に言えば、このような迷惑なエラーを検出するのはそれほど簡単ではありません。 特に、例ではなく実際のエージェントを扱う場合、そのロジックと実装ははるかに複雑になる可能性があります。

ブラックボックス効果とそれに対して何をすべきか？

上記の例では、SObjectizerが「ブラックボックス」になっているという事実に直面しています。 彼にいくつかのコントロールアクションを与えますが、必要な結果は発生しません。 しかし、なぜですか？ その理由は何ですか？ この理由の一番下に到達するには？



そして、ここで理由の底に到達することはそれほど簡単ではないことがわかります。 小さな例をなんとかしてデバッグする必要がありますが、どのようにそれを行うのでしょうか？



デバッガを使用する場合、いくつかの場所にブレークポイントを設定できます。 例：



1. pingの最初の送信が呼び出されることを確認するために、pinger :: so_evt_start（）メソッドで。



2.ポンガーエージェントのpingシグナルハンドラーで、最初のpingが到着し、応答としてポンが送信されることを確認します。



または、私たちが本物のプログラマであり、デバッガが弱虫用であると信じている場合は、これらの場所にデバッグプリントを配置できます。



これらのアクションを実行すると、so_evt_start（）が呼び出され、pingの最初の送信が実行されますが、pongのハンドラーは呼び出されません。 しかし、なぜですか？ コンストラクターでサブスクリプションを作成しました...



ここで、SObjectizerを使用する開発者の直前に、「しかし、メッセージが配信される方法を理解するためにSObjectizerの内部をどのように見ますか？」という疑問が生じます。



質問は簡単ではありません。 プログラマが送信呼び出しをルーティングすることを決定した場合、まず、SObjectizer実装の詳細のジャングルに陥り、それを楽しむことはほとんどありません（ただし、一部の人は見て、ひどいことは何も見なかったが、信じる？）。 第二に、そして最も重要なこととして、彼はメッセージ配信が2つの部分で構成されていることを理解します。 最初の部分は、サブスクライバーの要求キューにメッセージを配置することです。 2番目の部分は、特定のアプリケーションのメンテナンスであり、特定のディスパッチャによってキューから削除されます。



そして、最初の部分で問題が明らかになったら。 たとえば、開発者は、メッセージのサブスクライバが存在しないため、メッセージに対するリクエストが生成されないことがわかります。 しかし、アプリケーションは生成されたが、ハンドラーが呼び出されなかった場合、プログラマーはSObjectizerの内部をさらに深く掘り下げる必要があります。 そして、彼はSObjectizerに異なるディスパッチャがあり、いくつかは非常に具体的で、他とは異なる動作をし、次のアプリケーションがキューから抽出および分析される場所を見つけることはそれほど簡単ではないことがわかります。



一般に、誰かがデバッガを使用してSObjectizerのメッセージ配信メカニズムを実行したい場合、この人は幸運を祈るだけです。 私たち自身はそのような娯楽の大ファンではないので。



さて、代替手段はありますか？



あります。 これは、 正式にはメッセージ配信トレース （または簡略化のためmsg_tracing） と呼ばれるメカニズムです 。 2年半前にSObjectizer-5に追加されました。 しかし、おそらく、彼について聞いたことのある人はほとんどいないでしょう。

Msg_tracingメカニズム

SObjectizerを起動すると、msg_tracingメカニズムを有効にできます。 有効にすると、SObjectizerはメッセージの配信と処理のプロセスを説明するテキストメッセージを生成します。 これらのメッセージは、特別なトレーサーオブジェクトに渡されます。 トレーサーのタスクは、トレースメッセージを保存するか、処理することです。 ユーザーは独自のトレーサーを実装するか、SObjectizerの既製トレーサーのいずれかを使用できます。



msg_tracingを含めることで上記の例を展開し、何が起こるか見てみましょう。 したがって、msg_tracingを有効にして、すべてのトレースメッセージを標準出力にマップする必要があることを示します。

 int main() { //  SObjectizer       . so_5::launch([](so_5::environment_t & env) { env.introduce_coop([](so_5::coop_t & coop) { //  ,   . const auto mbox = coop.environment().create_mbox(); //  . coop.make_agent<pinger>(mbox); coop.make_agent<ponger>(mbox); }); }, [](so_5::environment_params_t & params) { //     . //       . params.message_delivery_tracer(so_5::msg_tracing::std_cout_tracer()); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更された例を実行し、次のようなものを取得します。

  [tid = 13728] [mbox_id = 5] deliver_message.no_subscribers [msg_type = struct ping] [signal] [overlimit_deep = 1] 

このエントリは、deliver_message操作が進行中であることを示します。 同時に、そのような識別子を持つメールボックスに送信されるping信号のサブスクライバーがない状況が発見されました。



そのため、メッセージはメールボックスに送信されますが、誰も購読していません。 しかし、どのように、私たちはサブスクリプションをしました、ここにあります：

 //      . so_subscribe_self().event([this](mhood_t<ping>) { std::cout << "ping!" << std::endl; so_5::send<pong>(mbox_); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここでは、サブスクリプションを行ったことは既にわかりますが、そのmboxではまったくわかりません。 so_subscribe（mbox_）を呼び出す必要があり、so_subscribe_self（）を呼び出しました。 regularましい規則性で作られた不幸な間違い。 msg_tracingメカニズムにより、デバッガーをSObjectizerの内部に突入させることなく、問題に迅速に対処できました。

msg_tracingはデバッグメカニズムです

心に留めておくべき最も重要なことは、msg_tracingがデバッグのヘルパーメカニズムであることです。 SObjectizerに基づいて開発されたアプリケーションのデバッグを開発者が支援するために作成されました。



特に、msg_tracingには追加のオーバーヘッドコストがあり、メッセージの送受信コストが大幅に増加します。 そのため、msg_tracingを明示的に有効にする必要があります。これは、SObjectizerを起動する前に一度だけ実行されます。 msg_tracingを有効にしてSObjectizerを起動した後、msg_tracingを無効にすることはできません。 すべてが非常に深刻なので、SObjectizer内でmsg_tracingをオンにすると、追加のデータと追加のコードの両方を含む他のデータ構造が使用されます。 そのため、SObjectizer内で、msg_tracingがオンになっている場合、他のmboxタイプが作成されます。



したがって、msg_tracingは、SObjectizerアプリケーションをデバッグするための補助ツールと見なす必要があります。 また、本番環境で動作する必要のある手段をその基礎の上に構築しないでください。

msg_tracingメカニズムの現在の状態：その欠点と可能な解決策

msg_tracingメカニズムは、2015年10月にバージョン5.5.9に追加されました。 それでも、このメカニズム自体はまだ初期段階にあることが明らかでした。 何かから始める必要がありました。実際に試してみて、経験を積んで、どこに進むべきかを理解できる何かを手に入れる必要がありました。



過去に、既存のmsg_tracingメカニズムに2つの重大な誤算/弱点が確認されています。

トレースメッセージフィルタリングなし

SObjectizerの開始時にmsg_tracingが有効になっている場合、SObjectizerはメッセージ配信に関連するすべての操作のテキストトレースメッセージを作成し、これらのメッセージをトレーサーオブジェクトに渡しました。 これは、msg_tracingを使用して小さなアプリケーション、例、またはテストをデバッグする場合には問題になりません。 しかし、数百万のメッセージを交換する数百のエージェントを含む大規模なアプリケーションでmsg_tracingを使用しようとすると、これは問題です。 なぜなら プログラマが必要としないトレースメッセージを何らかの形で除外する必要があり、テキストトレースメッセージでこれを行うのはそれほど簡単ではありません。



したがって、トレーサーに送信される前にトレースメッセージをフィルター処理する機能をユーザーにSObjectizerに与えるという話が時々ありました。 さらに、フィルターは最終的に形成されたテキストメッセージを処理するのではなく、テキストに変換されるデータを処理する必要があります。

トレースメッセージのフローを制御する方法はありません

時々、ブロックされたトレースメッセージでSObjectizerを実行し、ある時点で「蛇口を開けて」、トレースメッセージがトレーサーに入るようにしたいことがあります。 そして、「タップをシャットオフ」。



したがって、SObjectizerの動作中にmsg_tracingのオンとオフを切り替えることができる会話が時々ありました。 ここでの難しさは、SObjectizerの開始時に、開発者がmsg_tracingを使用することを既に知っている必要があることでした。 この場合、SObjectizerは他のタイプのmbox-sを作成し、メッセージ配信の他の方法を使用します（何が起こっているかをトレースします）。

バージョン5.5.22で予定されているmsg_tracingの変更

先日、SObjectizerの新しいバージョンの最初のアルファを修正しました。 msg_tracingメカニズムの拡張を実装します。 トレースメッセージのフィルターの概念が追加されました。



フィルターはオプションです。 フィルターが割り当てられている場合、SObjectizerは、テキストトレースメッセージを生成する前に、現在のトレースメッセージのさらなる処理を許可するかどうかを最初にフィルターに問い合わせます。 フィルタに「はい、できます」と表示されている場合、テキストトレースメッセージが生成され、トレーサオブジェクトに送信されます。 フィルターが「いいえ、できません」と答えた場合、トレースメッセージは生成されず、どこにも行きません。



フィルターがない場合、SObjectizerは以前と同様に機能します。テキストトレースメッセージが生成され、トレーサーオブジェクトに送信されます。 つまり プログラマーがフィルターについて知らない場合、またはフィルターを使用したくない場合、msg_tracingメカニズムは以前と同様に動作します。



さらに、バージョン5.5.22のSObjectizerでは、作業中にmsg_tracingフィルターを設定および削除できます。

バージョン5.5.22でのmsg_tracingフィルターの使用例

msg_tracingメカニズムの新機能を示すために、次の例を取り上げます。 ほとんど同じように機能する2つのエージェントがあります。 これらには3つの状態があります：最初、2番目、3番目。 各状態で、エージェントは2種類のメッセージに応答する必要があります。 change_stateに従って、次の状態（つまり、1番目から2番目、2番目から3番目、3番目から1番目）に移動する必要があります。 ティックメッセージが到着した場合、エージェントはそれに応答するだけです。 反応がどうなるかは重要ではありません。



1番目と2番目のエージェントの違いは、最初のエージェントが各状態のティックメッセージに応答することです。 しかし、2番目の状態のティックメッセージをサブスクライブした2番目のエージェントは忘れていました。 したがって、2番目のエージェントは、2番目の状態にあるときにティックメッセージを失います。 msg_tracingメカニズムを使用して検出したいのは、まさにこれらの損失です。



これを行うには、次の形式のトレースフィルターをインストールする必要があります。

 //    ,    //  -  .    , //        . so_environment().change_message_delivery_tracer_filter( so_5::msg_tracing::make_filter( [](const so_5::msg_tracing::trace_data_t & td) { //      . const auto handler_ptr = td.event_handler_data_ptr(); if(handler_ptr) { //    trace- . //   ,    . if(nullptr == *handler_ptr) //   .    , //   . Trace-  . return true; } //      trace-. return false; }));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たぶん怖いですね。 しかし、それを理解してみましょう。



change_message_delivery_tracer_filter（）メソッドを使用すると、SObjectizerの実行中にトレースフィルターを交換できます。



ヘルパー関数make_filterは、ラムダ関数から必要なSObjectizerタイプのオブジェクトを作成します。



唯一の引数は、このラムダ関数に渡されます-trace_data_tインターフェイスへのリンク。このインターフェイスから、フィルターはトレースメッセージに関連するデータを抽出できます。 この特定の場合、trace_data_tを唯一のevent_handler_data_ptr（）メソッドと呼びます。 このメソッドは、オプションの<const event_handler_data *>を返します。 したがって、オプションの内部は、ポインタにすることも、しないこともできます。 ポインターがない場合、トレースメッセージは興味深いものではありません。 メッセージハンドラの検索には適用されません。 ポインターはあるがヌルである場合、これはまさに私たちが待っているケースです。SObjectizerはメッセージのハンドラーを見つけようとしましたが、何も見つかりませんでした。 この場合、この場合のみ、トレースメッセージを有効にします。



この例を実行すると、コンソールに次のメッセージが定期的に表示されることがわかります。

  [tid = 11880] [agent_ptr = 0x23be91d7cb0] demand_handler_on_message.find_handler [mbox_id = 6] [msg_type = struct base :: tick] [signal] [state = second] [evt_handler = NONE]
 [tid = 11880] [agent_ptr = 0x23be91d7cb0] demand_handler_on_message.find_handler [mbox_id = 6] [msg_type = struct base :: tick] [signal] [state = second] [evt_handler = NONE]
 [tid = 11880] [agent_ptr = 0x23be91d7cb0] demand_handler_on_message.find_handler [mbox_id = 6] [msg_type = struct base :: tick] [signal] [state = second] [evt_handler = NONE]
 [tid = 11880] [agent_ptr = 0x23be91d7cb0] demand_handler_on_message.find_handler [mbox_id = 6] [msg_type = struct base :: tick] [signal] [state = second] [evt_handler = NONE] 

さらに、それらは印刷されるか、印刷されません。 これは、トレースメッセージのストリームを「オン」または「オフ」にするtrace_controllerエージェントがあるためです。

現在、trace_data_tで利用できるものは何ですか？

trace_data_tインターフェイスは現在、次のように定義されています。

 class trace_data_t { ... public : //  ID  ,    . virtual optional<current_thread_id_t> tid() const noexcept = 0; //     ,    . virtual optional<std::type_index> msg_type() const noexcept = 0; //    ,     . virtual optional<msg_source_t> msg_source() const noexcept = 0; //   -,   . virtual optional<const agent_t *> agent() const noexcept = 0; //        . virtual optional<message_or_signal_flag_t> message_or_signal() const noexcept = 0; //      . virtual optional<message_instance_info_t> message_instance_info() const noexcept = 0; //     . virtual optional<compound_action_description_t> compound_action() const noexcept = 0; //        . //    ,      //    . virtual optional<const so_5::impl::event_handler_data_t *> event_handler_data_ptr() const noexcept = 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このすべての情報がトレースメッセージに常に利用できるとは限らないことを特に強調する必要があります。 たとえば、サブスクライバー間で配信するためにメッセージがメールボックスに送信された場合、event_handler_data_ptr（）は空のオプションを返します。 メールボックスにこのタイプのメッセージへのサブスクライバーがない場合、agent（）メソッドは空のオプションを返します。

なぜこれがすべて説明されたのですか？

この記事は、興味のある開発者がSObjectizerの次のバージョンで何が待っているかを事前に知ることができるようにするために書かれました。したがって、彼らは提案されたイノベーションに慣れ、それらを感じ、心を整え、何か気に入らない場合は「ファイ」を表現できます（so-5.5.22-alpha1がダウンロード可能、githubのミラーも更新されました））



したがって、最終バージョン5.5.22を修正する前に、何をどのように改善すべきかを理解する機会が得られます。これは私たちにとって重要です。なぜなら、バージョン間の互換性を維持するというトピックに飛びついており、この非常に互換性を壊したくないからです。



だから誰かがこのトピックに興味があるなら、コメントで話してください。設計上の考慮事項に耳を傾けます。



PS。この記事で使用されている例は、このリポジトリにあります。



PPS また、バージョン5.5.22では、イベントハンドラーの時間に関する統計を収集するより高度なバージョンを作成する計画もありました。ただし、このトピックに関する追加のフィードバックが得られない場合、このタスクの優先度は低くなり、ほとんどの場合、リリース5.5.22にはなりません。