私のアプリケーションとしてJetty 7を使ってJetty Webソケットを使用しています。Webソケットの切断の理由がわかった
アプリケーションでは、Web Socketを介して1秒ごとにデータが連続的に流れています。また、アプリケーションの設計に従って、ソケットが4分間アイドル状態の場合、ソケットは切断されます。
私たちのアプリケーションでウェブソケット切断が発生しました。ウェブソケット切断理由の原因を調べることができません。これは、ソケットが4分間アイドル状態であるか、ネットワークレベルで何か起こったためです。すべての切断については、ロードバランサ、ファイアウォール--etc)
、桟橋内部理由コード1006(クローム)
として私は切断のための実際の理由が起こったのかを知ることができます教えてください?
ウェブソケットのトラフィックを監視する方法はありますか?
私は、ChromeデバッガーツールのWebsocketタブを使ってトラフィックを監視しようとしましたが、一度切断すると、その時点でWebsocketに存在するデータのクローズはありませんか?
このケースを処理する方法についてアイデアをお伝えください。これは、WebSocketを探す理由を調べる方法です。
1006はローカル側のクローズコードです。任意のエンドポイントがWebSocket Closeコントロールフレームで送信してはならない(MUST NOT)。 [RFC-6455 Section 7.4.1](http://tools.ietf.org/html/rfc6455#section-7.4.1)を参照してください。 –
私はクライアント側とサーバ側の接続で大規模なjetty-8クライアントからjetty-9サーバーへのデータメッセージ。サーバー上の最大メッセージサイズを増やすことで修正しました。 – Sanjeev
Jetty 9サーバーは、そのシナリオではステータスコード1009(メッセージが大きすぎます)で応答します。 –