Estranha experiência de usuário final com Liferay, Glassfish e Apache em RedHat

Question

Tentei vários fóruns para chegar ao fundo disso. Espero conseguir alguma orientação aqui:

Aqui está a pilha com a qual estou trabalhando: Servidor Red Hat Enterprise Linux versão 5.6 (Tikanga) Liferay 6.0.6 no Glassfish 3.0.1 MySQL 5.0.77 Apache 2.2.3

O portal Liferay fornece uma variedade de portlets para usuários finais. Conteúdo estático (páginas da web), recursos estáticos (principalmente arquivos pdf e mp3 de 1mb - 80mb), capacidade de upload e download de arquivos (principalmente arquivos mp3 40-60mb) e streaming online desses arquivos MP3.

Aqui estão as experiências estranhas do usuário final: Sob carga normal: (20-30) usuários fazendo upload, download ou streaming de arquivos e 20-30 acessando conteúdo estático (alguns deles são baixados), vemos o seguinte:

1) Clicar em um link aciona o download de uma parte de um MP3 (a parte dura alguns segundos).

2) Clicando em um link tiggers o download do conteúdo da página, em vez de renderização.

3) Clicando em um link faz com que a página despeje dados binários para o usuário final em vez do conteúdo esperado.

4) Clicar em um link retorna o texto de um arquivo javascript em vez de renderizar a página.

Cada ocorrência é totalmente aleatória (ou aparece assim). Às vezes funciona, às vezes não. Parece não ter relação com o navegador ou sistema operacional cliente. Os eventos estranhos parecem ocorrer com muito mais frequência quando se usa uma conexão SSL em vez de http regular.

O Apache serve apenas como servidor proxy (reverso). Basicamente, passa todos os pedidos para o Glassfish. Não há nenhum proxy de conteúdo estático veiculado pelo Apache.

Reconstruímos toda a pilha desde o início e reimplementamos as guerras do portlet e ainda temos os mesmos problemas. O Liferay está sendo executado como um único servidor (não em cluster). Nós desativamos o mod_cache no Apache. Os problemas são mais frequentes à medida que a carga do servidor aumenta. Esta manhã a carga é bastante leve e estamos vendo poucos problemas, mas o uso do site vai crescer, particularmente hoje à noite por volta das 21h CST até a manhã de quarta-feira. Você poderia tentar o site ( link ) durante esses momentos e eu esperaria que você experimentasse uma das estranhezas à medida que você clica aleatoriamente nos links site (https é invocado somente quando conectado). Mais uma vez, https parece exacerbar o problema.

Isso parece muito com um problema de armazenamento em cache, mas não sei onde está a pilha para começar a descascar a cebola. Apache? Liferay? Peixe de vidro? MySQL? Talvez até Redhat? Estamos perplexos e a maioria dos fóruns que postamos (LifeRay e Glassfish) retornaram muito poucas sugestões. Eu só preciso de uma ideia de onde começar a procurar. Eu entendo que poderíamos ter um portlet

EDIT: Abrindo os arquivos em um editor hexadecimal que parecem ser páginas que baixam ao invés de renderizar, vemos que os primeiros 4000 caracteres são "lixo" e então o cabeçalho "HTTP / 1.1 ...." 'normal' é visto. Então, algo está despejando uma confusão de caracteres para compensar 4000 (quando visualizá-lo em um editor Hex). Talvez uma pista?

EDIT2: O deslocamento de 4000 h é 16k (16384). Eu estou pensando que isso é um problema de cache, mas não sei onde procurar configurações de cache deste tamanho. Eu vejo referências a buffers de cache 16k LRU no Apache, mas eu sei que Glassfish (ou talvez Liferay) usa ehcache. Isso desencadeia algum pensamento para alguém? Idéias?

    

Answer 1

A chave para descobrir onde seu problema está localizado é remover partes diferentes da equação - ou interceptar o tráfego onde você não pode.

Por exemplo:

• Você pode tentar deixar o Apache fora. Se você não puder fazer isso para o acesso público, poderá tentar reproduzir acessando o glassfish por trás do firewall enquanto também está servindo conteúdo através do Apache - ou configurar um sistema de espelhamento completamente separado do sistema de produção e tentar reproduzi-lo. Outra alternativa é o wireshark / gravar o tráfego entre o apache e o glassfish
• Se você conseguir reproduzir dessa forma (sem apache), configure o mesmo sistema no tomcat, coloque isso sob carga (talvez carga artificial, pois não quer fazer isso em produção, com hardening etc.)
• Se você não pode reproduzir sem o apache, desmonte a configuração do apache - elimine o gzip, elimine (ou force) o https, conecte o Apache / Glassfish com mod_jk ou mod_proxy (o outro do que você está usando agora)

Como o problema parece estar no lado do HTTP (gerando respostas HTTP ilegais), eu esperaria que o banco de dados fosse descartado como causa.

E algumas sugestões menos técnicas:

Outra abordagem geral para esse tipo de problema é fazer com que outra pessoa dê uma olhada sem que você diga o que você já fez - sente-se lá e deixe-os explicar o que eles estão olhando, talvez você encontre algo que não ainda não passou pela sua cabeça ou que você não verificou antes.

E, para jogar truques em sua mente: Use um computador ou mesa diferente para realizar o teste: Mudar a perspectiva física para observar um sistema às vezes é uma boa causa para pensamentos diferentes. Soa estúpido, mas às vezes o cérebro quer ser enganado.

    

Answer 2

Então aqui está a resposta (não a resposta completa, mas pelo menos a solução). Tínhamos um portlet de terceiros que impunha uma conexão SSL em determinadas URLs que tinham \ secure na URL. Removemos esse portlet e o problema desapareceu.

Quando tiver a chance de examinar o código, talvez consiga descobrir o que no portlet estava causando o problema. Mas corremos sem problemas por algumas semanas e o portlet foi definitivamente a causa (AFAIK).