4

Chris Fulstowプロジェクトlog4net.signalrを知っています。すべてのリクエストからのすべてのメッセージをログに記録するため、非本番ログが必要な場合は素晴らしいアイデアです。ログメッセージを発信し、適切なブラウザにsedバックするリクエストによってログメッセージを区別するものが欲しいのですが。

これが私がアペンダーでしたことです：

 public class SignalRHubAppender:AppenderSkeleton
    {
        protected override void Append(log4net.Core.LoggingEvent loggingEvent)
        {
            if (HttpContext.Current != null)
            {
                var cookie = HttpContext.Current.Request.Cookies["log-id"];
                if (null != cookie)
                {
                    var formattedEvent = RenderLoggingEvent(loggingEvent);
                    var context = GlobalHost.ConnectionManager.GetHubContext<Log4NetHub>();
                    context.Clients[cookie.Value].onLog(new { Message = formattedEvent, Event = loggingEvent });
                }
            }
        }
    }

セッションIDをCookieに添付しようとしていますが、Cookieが上書きされるため、同じマシンでは機能しません。これは、イベントを添付するためにクライアントで使用するコードです。

//start hubs
    $.connection.hub.start()
    .done(function () {
        console.log("hub subsystem running...");
        console.log("hub connection id=" + $.connection.hub.id);
        $.cookie("log-id", $.connection.hub.id);
        log4netHub.listen();
    });

その結果、接続されている最後のページだけにログメッセージが表示されます。現在のリクエストを発信するブラウザからの現在の接続IDを取得するための戦略があるかどうかを知りたいのですが、ある場合は。また、ブラウザごとのロギングを実現するためのより良い設計があるかどうかを知りたいと思います。

編集

慣例的な名前ベースのCookie（log-id-someguidなど）を作成することもできますが、もっとスマートなものがあるのではないかと思います。

バウンティ 私はその質問にバウンティを開始することに決めました。さらに、私の戦略が理にかなっているかどうかを確認するために、アーキテクチャについて質問します。私の疑問は、サーバーからクライアントへの単一の「方向」でハブを使用しており、ハブへの呼び出しからではなく、他の要求（他のハブで発生する可能性のある要求）から発生したアクティビティをログに記録するために使用しています。その正しいアプローチは、ブラウザに表示されるlog4netアペンダーを目標として持っていますか？

4

1 に答える 1

2

同じSPAで複数のタブが開いている場合でも、適切なブラウザインスタンス/タブを正しくターゲットにする方法についての考え方は、URLを介してそれらを区別することです。これを実装するための1つの可能な方法は、http： //foo.comからhttp://foo.com/hhd83hd8hd8dh3への最初のアクセス時にそれらをリダイレクトすることです。、毎回ランダムに生成されます。そのURLの書き換えは他の方法でも行うことができますが、これは問題を説明するための方法にすぎません。このようにして、アペンダーは元のUrlを検査できるようになり、Urlからサーバー側に保持するマッピングを介して、適切なSignalRConnectionIdを識別できます。実装の詳細は異なる場合がありますが、基本的な考え方はこれです。最初の接続以降、HttpContextで利用可能ないくつかの情報を追跡して、ハイジャックを防ぐために追加の戦略を立てることもできます。

あなたのアーキテクチャについては、これがまさに私がElmahRで使用した方法であると言えます。通知ハブの外部から発信されたメッセージ（他のWebアプリから投稿されたエラー）があり、そのハブに接続されている（および特定のグループをサブスクライブしている）すべてのクライアントにブロードキャストを実行します。正常に動作します。

私は信頼できる情報源ではありませんが、複数のハブがあっても、そのようなアーキテクチャは問題ないと思います。これは、1日の終わりのハブは、（1つの）永続的な接続を抽象化したものであり、コンテキスト。舞台裏（私は単純化しています）では、メッセージが行き来する永続的な接続があるだ​​けなので、その上に定義するハブ構造（物事を整理するためだけにあります）は、引き続きその接続を主張しますが、だからあなたは害を及ぼすことはできません。

SignalRは、大規模なブロードキャスト（クライアント）と1対1の通信（発信者）の2つのことを行うのに適しています。特定の呼び出し元へのサーバー側の参照を維持するような奇妙なことをしようとしない限り、ハブの数やハブ間の相互作用に関係なく、問題はありません。

これらは私の結論であり、現場から来ています。たぶん、あなたはこの質問について@dfowlerをひねって、彼が（はるかに）より信頼できるガイドラインを持っているかどうか見ることができます。

于 2012-09-18T08:53:01.663 に答える