Сервер Jetty сбрасывает запрос, исходящий из того же порта, с клиентского компьютера.Время ожидания клиента - PullRequest
Новая
       18

Сервер Jetty сбрасывает запрос, исходящий из того же порта, с клиентского компьютера.Время ожидания клиента

0 голосов
/ 14 декабря 2011

Я использую Jetty7 в качестве REST-сервера. При обработке запросов REST я поддерживаю соединения webdav от клиентов Win7. Моя проблема такова:

  • (1) Если я дважды щелкну файл, Клиент отправит запрос GET для файла. Когда он захвачен в wireshark, он показывает, что запрос исходил от клиентского порта 54456 к серверному порту 80, где работает Jetty.

  • (2) Запрос приходит к моему REST-обработчику для GET, а затем я строю ответ следующим образом:

ResponseBuilder builder = javax.ws.rs.core.Response.ok ();
builder.header («Keep-Alive», «timeout = 15, max = 99»);
builder.header («Соединение», «Keep-Alive»);
builder.header («Cache-Control», «no-store»);
builder.header («Accept-Ranges», «bytes»);
builder.header («Last-Modified», новый формат Rfc1123DateFormat (). (new Date (lastModified)));
builder.header («Content-Length», fileLength);
InputStream in = new BufferedInputStream (in); // 'in' был InputStream, который я получил из другого модуля и имеет файл содержание.
возвращение builder.entity (in) .build ();

Здесь 'in' - это BufferedInputStream, в котором содержится запрошенный файл.

  • (3) Файл открывается на клиентском компьютере. Но в моей трассировке пакета заголовок ответа не содержит записи: Соединение: Keep-Alive ... Странно !!!

  • (4) Затем я дважды щелкнул папку с клиента. Это отправило запрос PROPFIND на сервер. Запрос снова поступил с клиентского порта 54456. Я также поместил перехват пакетов на сервер. Трассировка на сервере подтвердила, что запрос PROPFIND достиг сервера с порта № 54456 ..... но мой обработчик так и не был вызван. В конечном счете, клиент продолжает ждать и время ожидания. После этого либо клиент пытается снова, либо выдает ошибку, что путь не найден.

  • (5) Но если запрос PROPFIND исходит из любого другого порта (на котором исходил предыдущий запрос GET), то сервер Jetty обрабатывает его, и мой обработчик вызывается ...

  • (6) Еще одно наблюдение: если последовательность вызовов от клиента такова: первый клиент отправляет PROPFIND из порта клиента, скажем, 54400, и сервер отвечает. Затем снова PROPFIND из того же порта, затем причал обрабатывает это тоже .. Но только GET, сопровождаемый каким-то другим запросом, заставляет причал не отвечать.

Я попытался увеличить / уменьшить maxIdleTimeOut внутри файла Jetty.xml, но ничего не помогает. Я хочу знать, возможно ли заставить причал обрабатывать эти запросы ... Либо через некоторое изменение кода в моей области, либо через некоторое изменение конфигурации. ИЛИ если вы видите какое-то неправильное кодирование, сделанное мной ...

спасибо, Анил.

1 Ответ

0 голосов
/ 15 декабря 2011

Я нашел решение для моей проблемы после небольшого изменения кода.Я изменил способ реализации обработчика GET.Теперь я принимаю HttpServletResponse внутри параметра функции и получаю OutPutStream из этого.Затем продолжайте чтение из объекта «in» (который является входным потоком) и запись в объект OutPutStream, который будет записан непосредственно в ответ клиента.Конечно, перед записью потока мне пришлось установить заголовки объекта HttpServletResponse.

И я удалил использование объекта ResponseBuilder.то есть я полностью удалил использование объекта builder (который был написан в моем вопросе выше) и переключился на объект HttpServletResponse ...

При этом похоже, что jetty не удерживает соединение для длинных и последующих последующих запросов.которые исходят из того же порта клиента, принимаются и передаются моему обработчику.

...