Почему мои загрузки артефактов и архивов зависают через VPN?

Я столкнулся с очень странной проблемой, и я не уверен, что происходит. Я пробовал много перестановок, и я не могу решить эту проблему. Любое понимание будет очень признательно. Вот моя среда:

Я установил архив и репозиторий артефактов в промежуточной зоне, доступ к которой возможен только через Cisco VPN. Мне не нужны оба кеша, но я экспериментировал с обоими, пытаясь решить проблему.

Я создаю свое программное обеспечение с помощью gradle, но это не проблема. Когда мой проект собирается, он довольно долго загружает файлы POM и JAR. Однако каждый раз он «застревает» в банке. Для этого конкретного локального снимка загрузок я могу запустить сборку N раз, и она зависнет на одном и том же месте. Если я удалю свой локальный кеш, он может зависнуть в другой банке.

Скорость передачи VPN не велика (100-200К/с) и непосредственно перед зависанием она значительно замедляется, вплоть до 0. Кроме того, если я встрою промежуточный сервер, передачи будут осуществляться по сети 10G и все работает просто отлично.

Я использовал wget для загрузки банок, и вывод обычно выглядит так:

/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% или более, но не завершается. Журналы не указывают на ошибку. Я пробовал tomcat 6, tomcat 7, jetty, java 6, java 7, прокси-сервер squid на артефактном сервере, чтобы попытаться обмануть его при локальной загрузке.

Я проверил трафик с Чарльзом и просмотрел журналы, и, насколько я могу судить, сервер думает, что отправил все данные, а клиент застревает в ожидании последних нескольких байтов. У меня совсем нет идей. есть идеи?


vpn artifactory jetty tomcat archiva
person Julio Garcia    schedule 11.10.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я видел, как это происходит из-за того, что пакеты Jumbo конвертируются в стандартный пакет TCP/IP. Случилось так, что Tomcat по умолчанию отправляет большие пакеты большого размера (размер буфера -MTU- 9000 байт), которые сетевые маршрутизаторы разрезают на более мелкие пакеты, поскольку сеть не поддерживает пакеты большого размера. Таким образом, в некоторые моменты Tomcat отправляет блок «конец пакетов», который получен «до» прибытия всех остальных подпакетов. Вывод, он зависает или отключается до получения всех данных.

Обходной путь состоит в том, чтобы изменить размер буфера в файле tomcat server.xml примерно на 1500 или настроить конфигурацию карты TCP/IP сервера на 1500 MTU (раздражает для локальной сети 1G).

Надеюсь это поможет.

person Fred Simon    schedule 14.10.2012
comment
Спасибо, сам бы до этого не додумался. - person jgrowl; 01.10.2013