ZEUS ZXTM interrompe a solicitação HTTP para um Java Servlet HTTP 404?

1

Eu tenho um Java Servlet chamado "ARI" que recupera dados de um banco de dados de archive e retorna uma carga XML com linhas desse banco de dados.

Temos várias instâncias deste servlet sendo executadas em servidores virtuais a partir de uma caixa e podem ser acessadas por um número de porta diferente da seguinte forma:

testserver.co.uk:61061/aricp/ari

testserver.co.uk:61062/aricp/ari

Ambos os servlets podem ser acessados com sucesso diretamente do cliente. Aqui está uma amostra de conversação entre cliente e servidor feita pela captura de pacotes.

Solicitação HTTP bem-sucedida:

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

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

User-Agent: Java/1.6.0_25

Host: testserver.co.uk:61061

Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2

Connection: keep-alive

Content-Length: 11

id=1-134ISR

observe a variável POST "id" no pedido

Resposta bem sucedida

HTTP/1.1 200 OK

Server: Sun-ONE-Web-Server/6.1

Date: Tue, 08 Jan 2013 17:48:49 GMT

Content-type: text/html

Transfer-encoding: chunked

03a6

* Log de servidor de solicitação HTTP bem-sucedido *

[09/Jan/2013:10:25:33] fine (16359): for host 10.232.191.87 trying to GET /aricp/ari, ntrans-j2ee reports: mapped uri "/ari" in context "/aricp" to resource "ARI"

Portanto, não há problema em enviar solicitações diretas ao nosso servlet. No entanto, se usarmos o ZEUS ZXTM para manipular indiretamente as solicitações do cliente para todas as instâncias do nosso servlet, isso não funcionará.

Aqui está uma falha na Solicitação HTTP e observe a diferença no endereço HOST, já que o ZEUS é o intermediário.

Solicitação HTTP com falha de ZEUS

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

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

User-Agent: Java/1.6.0_25

Host: zeus.co.uk:61061

Accept: text/html, image/gif, image/jpeg, *; q=.2, /; q=.2

Connection: keep-alive

Content-Length: 11

id=1-PUZK7D

Resposta HTTP falhada por ZEUS

HTTP/1.1 404 Not found

Server: Sun-ONE-Web-Server/6.1

Date: Tue, 08 Jan 2013 18:05:45 GMT

Content-length: 292

Content-type: text/html

Ao usar o ZEUS, o servidor web não consegue interpretar a requisição vinda do ZEUS como uma requisição de servlet, em vez disso, parece interpretar o URI do pedido como um caminho de arquivo literalmente e nós obtemos um 404 não encontrado.

Log do servidor de solicitações HTTP com falha do ZEUS

[09/Jan/2013:10:50:45] warning (16886): for host 10.232.184.53 trying to GET /aricp/ari, send-file reports: HTTP4142: can't find /u02/SunONE61060/docs/aricp/ari (File not found)

Como você pode ver, trata-se do uri como um caminho de diretório em vez de um caminho de aplicativo.

Este é um problema muito estranho.

Coisas que tentei

  • Removendo a lista de controle de acesso para garantir que nenhum acesso seja restrito
  • Atualizando o servlet e o servidor virtual
  • Atualizando ZEUS
  • Reiniciando o servidor Web Sun One
  • Reinstalando o servlet no servidor virtual

Então, em resumo, está funcionando bem assim:

Client --> Server

No entanto, não está funcionando ao fazer isso:

Client --ZEUS --> Server

Estou prestes a ir e atualizar a instalação de um novo servidor virtual e ver o que acontece.

Todas as ideias ou teorias são bem-vindas.

    
por tomaytotomato 09.01.2013 / 11:16

1 resposta

1

Não sei por que você tem apenas um único servidor de back-end, talvez seja apenas uma configuração de teste.
ZXTM é um balanceador de carga poderoso, parece que você mais ou menos usá-lo como um proxy reverso atualmente.

De qualquer forma, a maneira como você costuma configurar algo assim é:
- crie um registro DNS como myapp.example.com e aponte para um IP de tráfego do cluster do ZXTM. - configurar seu aplicativo backend para ouvir myapp.example.com
- criar um servidor virtual no cluster do ZXTM que usa o IP do tráfego - crie um novo pool no cluster do ZXTM e adicione testserver.co.uk:61061 a ele | - atribuir o novo pool ao servidor virtual criado

Você pode acessar seu aplicativo por meio de myapp.example.com .
Você ainda pode acessar o aplicativo diretamente nos nós de back-end (por exemplo, para fins de monitoramento), mas dependendo de como o aplicativo funciona, talvez seja necessário ajustar o cabeçalho do host para isso.

    
por 09.01.2013 / 11:55