ZEUS ZXTM прерывает HTTP-запрос к сервлету Java HTTP 404?

У меня есть сервлет Java под названием "ARI", который извлекает данные из архивной базы данных и возвращает полезную нагрузку XML со строками из этой базы данных.

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

testserver.co.uk:61061/aricp/ari

testserver.co.uk:61062/aricp/ari

Обе эти сервлеты могут быть успешно доступны непосредственно с клиента. Вот пример диалога между клиентом и сервером, полученный при захвате пакета.

Успешный HTTP-запрос:

POST /aricp/ari HTTP/1.1 Accept-Charset: UTF-8

Тип контента: application/x-www-form-urlencoded;charset=UTF-8

Пользователь-агент: Java/1.6.0_25

Ведущий: testserver.co.uk:61061

Принять: текст / HTML, изображение / GIF, изображение / JPEG, *; q =.2, /; д = 0,2

Подключение: keep-alive

Длина контента: 11

ID =1-134ISR

обратите внимание на переменную POST "id" в запросе

Успешный ответ

HTTP/1.1 200 ОК

Сервер: Sun-ONE-Web-Server/6.1

Дата: вторник, 8 января 2013 г. 17:48:49 GMT

Тип контента: текст / html

Передача-кодировка: чанки

03a6


* Успешный журнал HTTP-запросов *

[09 / Jan / 2013: 10: 25: 33] отлично (16359): для хоста 10.232.191.87, пытающегося получить GET /aricp/ari, отчеты ntrans-j2ee: сопоставили uri "/ari" в контексте "/aricp" с ресурсом "ARI"

Поэтому можно отправлять прямые запросы нашему сервлету, однако, если мы используем ZEUS ZXTM для косвенной обработки запросов от клиента ко всем экземплярам нашего сервлета, это не работает.

Вот неудачный запрос HTTP, обратите внимание на разницу в адресе HOST, поскольку ZEUS является посредником.

ZEUS Не удалось HTTP-запрос

POST /aricp/ari HTTP/1.1 Accept-Charset: UTF-8

Тип контента: application/x-www-form-urlencoded;charset=UTF-8

Пользователь-агент: Java/1.6.0_25

Ведущий: zeus.co.uk:61061

Принять: текст / HTML, изображение / GIF, изображение / JPEG, *; q =.2, /; д = 0,2

Подключение: keep-alive

Длина контента: 11

ID = 1-PUZK7D

ZEUS Failed HTTP Response

HTTP / 1.1 404 Не найдено

Сервер: Sun-ONE-Web-Server/6.1

Дата: вторник, 8 января 2013 г. 18:05:45 по Гринвичу

Контент-длина: 292

Тип контента: текст / html

При использовании ZEUS веб-серверу не удается интерпретировать запрос, поступающий от ZEUS, как запрос сервлета, вместо этого он, кажется, интерпретирует URI запроса как путь к файлу буквально, и мы получаем 404 не найден.

Журнал ZEUS Failed HTTP Request Server

[09/Jan/2013:10:50:45] предупреждение (16886): для хоста 10.232.184.53, пытающегося GET /aricp/ari, отчеты файла отправки: HTTP4142: не удается найти /u02/SunONE61060/docs/aricp/ari (файл не найден)

Как вы можете видеть, он рассматривает URI как путь к каталогу, а не как путь к приложению.

Это очень странная проблема.


Вещи, которые я пробовал

  • Удаление списка контроля доступа, чтобы гарантировать отсутствие доступа
  • Обновление сервлета и виртуального сервера
  • Освежающий Зевс
  • Перезапуск веб-сервера Sun One
  • Переустановка сервлета на виртуальном сервере

Итак, в итоге все работает нормально, вот так:

Клиент -> Сервер

Однако это не работает при этом:

Клиент --ZEUS -> Сервер

Я только собираюсь пойти и обновить установку нового виртуального сервера и посмотреть, что произойдет.

Любые идеи или теории приветствуются.

1 ответ

Решение

Я не уверен, почему у вас есть только один внутренний сервер, может быть, это только тестовая настройка.
ZXTM является мощным балансировщиком нагрузки, кажется, вы более или менее используете его в качестве обратного прокси в настоящее время.

В любом случае, обычно вы настраиваете что-то вроде этого:
- создать запись DNS как myapp.example.com и укажите его на трафик IP кластера ZXTM
- настроить ваше приложение для прослушивания myapp.example.com
- создать виртуальный сервер в кластере ZXTM, который использует IP трафика
- создать новый пул в кластере ZXTM и добавить testserver.co.uk:61061 к этому
- назначить новый пул созданному виртуальному серверу

Затем вы можете получить доступ к своему приложению через myapp.example.com,
Вы по-прежнему можете обращаться к приложению непосредственно на внутренних узлах (например, для целей мониторинга), но в зависимости от того, как работает приложение, вам может потребоваться настроить заголовок узла для этого.

Другие вопросы по тегам