Na minha empresa, possuimos um produto da Oracle UCM, Universal Content Management é um gerenciador de conteudo semelhante a OpenCMS.
Pois bem, o UCM foi instalado em cluster , a instalação fica em um filesystem compartilhado por duas maquinas, essas maquinas estão rodando redhat 4.7 e arquitetura delas são 64 bits.
Segundo a Oracle é a forma do UCM suportar cluster.
Estranhamente hj de manhã as duas maquinas sofreram kernel panic e causa do kernel panic foi um processo java :shock:
Fiquei surpreso, como java pode causar um kernel panic e derrubar duas maquinas ao mesmo tempo?
Como UCM estava rodando em uma JVM 1.6 a Oracle recomendou que fizemos o downgrade do java para 1.5 ou desligassemos hotspot compiler da jdk.
Segundo a oracle há um bug relacionado com hotspot compiler em um maquina de 64bit
Fizemos o downgrade para 1.5 e as maquinas aparentemente ficaram estaveis.
Há tempos atrás vi coisas meio mandrakes como esta com outras configurações e outros produtos.
Não descarto a possibilidade do seu erro já ter sido corrigido em versões mais recentes do Java do que a que estava instalada em seus servidores. Uma rápida googlada mostrou erros na hotspost de 64 bits.
O Redhat 4.7 já tem um ano desde o lançamento e provavelmente também já deve ter tido diversas atualizações que não sei se afetam seu problema mas que é sempre bom estar em dia.
Fora a possibilidade de ser uma idiosincrasia do Oracle UCM.
Mas no caso o melhor é mesmo seguir a instrução do fornecedor para o que ele julga ser a arquitetura homologada. Só que se vocês pretendem usar as máquinas para outras coisas ficarão engessados no Java 1.5 para todo o sempre.
Esse tipo de engessamento é uma das piores coisas que pode acontecer na área de TI da empresa. Ficar parado no tempo enquanto o resto do mundo está anos à sua frente.
Esse tipo de engessamento é uma das piores coisas que pode acontecer na área de TI da empresa. Ficar parado no tempo enquanto o resto do mundo está anos à sua frente.[/quote]
Já pensando nesse tipo de coisa que costuma ocorrer com clientes, a Sun dá aquela famosa “opção” de cobrar por uma versão antiga da JVM quando ela ficar obsoleta - é o caso do Java 5, que está nesse processo de “end of lifing” : http://www.sun.com/software/javaseforbusiness/index.jsp
Fizemos o downgrade primeiramente em uma maquina de teste e pegamos alguns erros, com XMLStream prq está classe foi adicionada somente no java 6.
Contornamos esse problema pegando a dependência stax-api.
Agora estranho como kernel do redhat permite que processo java, faça isso…
Esse tipo de engessamento é uma das piores coisas que pode acontecer na área de TI da empresa. Ficar parado no tempo enquanto o resto do mundo está anos à sua frente.[/quote]
