1

私は非常に奇妙な問題に直面していて、何が起こっているのかわかりません。私は多くの順列を試しましたが、これを解決できません。任意の洞察をいただければ幸いです。これが私の環境です：

CiscoVPN経由でのみアクセスできるステージングエリアにアーカイブとアーティファクトリポジトリを設定しました。両方のキャッシュは必要ありませんが、問題を解決するために両方を試してみました。

gradleを使用してソフトウェアをビルドしていますが、問題はないようです。私のプロジェクトがビルドされると、POMとJARをダウンロードするのにかなりの時間がかかります。ただし、毎回、瓶に「詰まって」しまいます。ダウンロードの特定のローカルスナップショットについては、ビルドをN回実行でき、同じ場所でハングします。ローカルキャッシュを削除すると、別のjarでハングする可能性があります。

VPN転送速度は大きくなく（100〜200K / s）、ハングする直前に大幅に遅くなり、0になります。また、ステージングエリアサーバーを構築すると、転送は10Gネットワ​​ークを介して行われます。すべてが正常に機能します。

私はwgetを使用してjarをダウンロードしましたが、出力は通常次のようになります。

/tmp > wget -vS http://git-jenkins01.aus.sf:8082/artifactory/ecomm-snapshot-plus-remote/org/codehaus/groovy/groovy/1.8.6/groovy-1.8.6.jar
--2012-10-11 09:51:41--  http://git-jenkins01.aus.sf:8082/artifactory/ecomm-snapshot-plus-remote/org/codehaus/groovy/groovy/1.8.6/groovy-1.8.6.jar
Resolving git-jenkins01.aus.sf (git-jenkins01.aus.sf)... 10.57.10.226
Connecting to git-jenkins01.aus.sf (git-jenkins01.aus.sf)|10.57.10.226|:8082... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Server: Artifactory/2.6.4
  X-Artifactory-Id: 583c10bfdbd326ba:71d02e01:13a5059d090:-8000
  Last-Modified: Thu, 09 Feb 2012 17:57:32 GMT
  ETag: 553ca93e0407c94c89b058c482a404427ac7fc72
  X-Checksum-Sha1: 553ca93e0407c94c89b058c482a404427ac7fc72
  X-Checksum-Md5: e7ddf15d2f343537549dbbfd860c5f5b
  Content-Disposition: attachment; filename=groovy-1.8.6.jar
  X-Artifactory-Filename: groovy-1.8.6.jar
  Content-Type: application/java-archive
  Content-Length: 5546084
  Date: Thu, 11 Oct 2012 15:51:47 GMT
Length: 5546084 (5.3M) [application/java-archive]
Saving to: `groovy-1.8.6.jar.7'

95% [======================================================================================================================================>       ] 5,278,650   --.-K/s  eta 3s

常に約90％以上で停止しますが、終了しません。ログにはエラーの兆候はありません。私はtomcat6、tomcat 7、jetty、java 6、java 7、アーティファクトサーバーのsquidプロキシを試し、ローカルダウンロードに騙そうとしました。

Charlesでトラフィックを調べてログを調べたところ、サーバーはすべてのデータを送信したと見なし、クライアントは最後の数バイトを待機してスタックしました。私は完全にアイデアがありません。何かご意見は？

4

1 に答える 1

2

ジャンボパケットが標準のTCP/IPパケットに変換されるためにこれが発生するのを見ました。何が起こったのかというと、Tomcatはデフォルトで大きなジャンボパケット（バッファサイズ-MTU- 9000バイト）を送信していますが、ネットワークはジャンボパケットをサポートしていないため、ネットワークルーターによって小さなパケットにカットされます。したがって、ある時点で、Tomcatは、他のすべてのサブパケットが到着する「前に」受信される「パケットの終わり」ブロックを送信します。結論として、すべてのデータが受信される前にハングするか、切断されます。

回避策は、tomcat server.xmlのバッファーサイズを約1500に変更するか、サーバーのTCP /IPカード構成を1500MTUに強制することです（1Gローカルネットワークでは煩わしい）。

お役に立てれば。

于 2012-10-14T11:31:07.903 に答える