Application Client モジュールを使用した EAR アプリケーションがあります。
この EAR ファイルが GlassFish v2にデプロイされ、Application Client モジュールがキャッシュに存在する場合、Application Client の起動中のクライアント マシンとサーバー間のトラフィック量は約 1 です。0.7KB。
しかし、このアプリケーションを GlassFish v3にデプロイし、アプリケーション クライアント モジュールを 2 回目または 3 回目に起動すると (キャッシュに既に存在するように)、アプリケーション クライアント起動時のクライアント マシンとサーバー間のトラフィック量は 10MB になります。
何が間違っている可能性がありますか?
更新 1
「Hello World」を出力するだけの Application Client コンポーネントを使用して単純な EAR プロジェクトを作成し、それを GlassFish v3 にデプロイしても、Application Client がキャッシュから起動されるたびに 5 ~ 6MB になります。
更新 2
問題をより深く掘り下げようとしています。GlassFish v3 のキャッシュからアプリケーションを起動すると、アプリケーション クライアントの各ライブラリ
の GlassFish v3 ログに次の例外が記録されます。
java.io.IOException: An established connection was aborted by the software in your host machine
例えば:
SEVERE: Adapter[/___JWSappclient/___system] s1as/glassfish/modules/webservices-osgi.jar
java.io.IOException: An established connection was aborted by the software in your host machine
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:100)
私は、トラフィックのオーバーヘッドが関連している可能性があると仮定しています。この問題については、インターネット上にいくつかの情報があります。しかし、明らかに公式の説明や修正方法はありません。
これは、この問題に関連する興味深いスレッドであり、いくつかの光を当てる可能性があります。
ティム(よりtjquinn)が状況についてコメントした方法は次のとおりです。
「確立された接続が中止されました」というメッセージは私たちが見たものですが、あなたが言ったように、起動には影響しないようです. 私は、Java Web Start が JAR のダウンロードを開始し、キャッシュされたコピーが最新であることを発見し、転送を中止すると思いますが、確認していません。これは起こるべきではありませんが、それが Java Web Start の問題なのか、Grizzly の問題 (基本的に GlassFish のトランスポート層) なのか、GlassFish 自体の問題なのかを正確に認識させている原因を特定できていません。
UPD 3同様の問題 について、「Old Nabble」で興味深い議論があります。また、アプリケーション クライアントを起動した後、Web サービスの障害の症状が発生しました。
UPD 4 Grizzly フォーラム (UPD 3 で言及されているスレッド) の Oleksiy Stashok は、Java Web Start フォーラムに質問を投稿することを提案しました。Java Web Start フォーラムのスレッドへのリンクは次のとおりです。