3

SignalRMVC4 サイトで NuGetの最新のものを使用しています。サンプル ハブ コード(または任意のコード)を使用すると、奇妙な接続の問題が発生します。すべてが正常に読み込まれ、SignalR はネゴシエート呼び出しを行い、"EventSource Connected" をログに記録して、connectionid を返します。問題は、signalR/connectトランスポートでリクエストを行うときに始まります。適切なヘッダーを含む 200 応答を返しますが、接続が開いたままになります。呼び出されたハブ メソッドがCallerまたはでメソッドを実行する場合、次のリクエストまで、または座って待機すると10 ～ 30 秒後にClientsブラウザで実行されません。何かがパイプに詰まっているようなもので、次のリクエストまたは何らかのクリーンアップ メカニズムによってフラッシュされます。

独自のアプリ プールを備えた新しい Web サイトで、このためのクリーンなプロジェクトを作成しました。この問題は、1 台のマシンでのみ発生し、IIS7.5 でのみ発生します。IIS Express または Cassini の下の同じマシンで同じプロジェクトを実行すると、正常に動作します。このプロジェクトは、約 1 か月前に最後に作業したときに問題なく実行されました。さまざまなブラウザーとさまざまな jQuery バージョンを試しました。マシン全体を再起動しようとしましたが、フィドラー/デバッガーで数時間を無駄にしました。

これは、テストが実行されるサーバー側のコードです。

public class Chub : Hub {
    public void CallMeBack() {
        Caller.callme();
    }
}

これで一日中吹き飛ばしました。誰かが助けてくれることを願っています!

4

1 に答える 1

4

圧縮は、SignalR で使用される EventSource、ForeverFrame などのストリーミング レスポンスではうまく機能しないため、現時点では圧縮をオフにすることが唯一の解決策です。

~/signalr パスだけの圧縮をオフにすることは可能かもしれません。後でそれを試して、この回答を結果で更新します。

更新: 徹底的な分析の結果、この問題は IIS でアプリケーション プールが「クラシック モード」に設定され、動的圧縮が有効になっている場合にのみ発生することがわかりました。このSignalR の問題に関する私のコメントを参照してください。"統合モード" アプリケーション プールを使用している場合、影響はなく、SignalR は期待どおりに動作します (圧縮が有効になっている場合でも)。

クラシック モード + 動的圧縮に行き詰まっている場合は、web.config に次を追加して、/signalr パスのみの圧縮を無効にします。

<location path="signalr">
  <system.webServer>
    <urlCompression doDynamicCompression="false"/>
  </system.webServer>
</location>
于 2012-10-17T17:40:16.220 に答える