0

ソケットを介して短い XML メッセージを交換することで相互に通信する、Java で書かれた一連のアプリケーションがあります。現在、開発中は、すべてのアプリケーションを同じワークステーションで実行しています。私たちの問題は、各方向で何万ものメッセージが交換された後、これらのプログラム間のソケット接続がハングする可能性があることです。

Eclipse デバッガーで問題を確認すると、接続の両端で同じコードの別々のインスタンスが実行されていることがわかります。両端は、write(String) 呼び出しを使用して、Socket に基づいて BufferedWriter に有効なメッセージを正常に書き込みました。両端は、BufferedWriter の flush() 呼び出しの完了を待ってブロックされているように見えます。コードに異常はなく、ハングするまで何千ものメッセージを問題なく実行できます。どちらの側でも例外はスローされず、待機は無期限に見えます。この問題は、Linux プラットフォームと Windows プラットフォームの両方で実行中に確認されています。

誰が何が起こっているのかを提案できますか?

4

4 に答える 4

2

両端は、write(String) 呼び出しを使用して、Socket に基づいて BufferedWriter に有効なメッセージを正常に書き込みました。両端は、BufferedWriter の flush() 呼び出しの完了を待ってブロックされているように見えます。

言い換えれば、両端が書き込みであり、読み取りではありません。したがって、書き込みが送信者のソケット送信バッファをオーバーフローした場合 (受信者のソケット受信バッファがいっぱいの場合に発生する可能性があります)、受信者が読み取っていない場合に発生する可能性があります。送信者はブロックします。これは、アプリケーション プロトコル エラーのようです。一方が送信しているときに、もう一方が受信している必要があります。または、一方または両方の端に別々の送信スレッドと受信スレッドが必要です。

于 2013-09-09T03:40:04.287 に答える
0

皆さんの考えに感謝します。私たちはそれを理解しました.十分に大きな視野をとった後、それはまったく神秘的ではありませんでした. EJP は正しい軌道に乗っていました。詳細を説明すると、各アプリによって開かれた各ソケットには、実際には読み取りスレッドが関与しており、メッセージが利用可能になるとソケットを読み取り、さらに処理するためにこれらをキューに入れました。これらの読み取りスレッドは、デッドロックしたソケットの両端で読み取りを待機していたため、昨日は説明がつかないように見えました。今日、よく見てみると、システム全体がバックアップされているように見えます。問題の特定のソケットは、新たに読み取られたメッセージをキューに入れようとしてブロックされませんでしたが、システム内の他のソケットはブロックされました。すべてのアプリが同じコードを使用して通信していたため、この「剛性」
私たちは今、何が起こっているのか、そしてそれを修正する方法を認識しています。再度、感謝します。

于 2013-09-10T03:13:01.357 に答える