Java e kernel panic

9 de julho de 2009 5 respostas

ramilani12 9 de julho de 2009

Olá
Pessoal,

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.

Nunca vi nada parecido.

5 Respostas

Luca 9 de jul. de 2009

Olá

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.

[]s
Luca

Bruno_Laturner 10 de jul. de 2009

Hear, hear!

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.

thingol 10 de jul. de 2009

Hear, hear!

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.

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

15 anos? Isso é realmente ficar engessado mesmo.

ramilani12 10 de jul. de 2009

Olá
Luca,

Faz tempo que vc nao aparece no forum

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…

ramilani12 10 de jul. de 2009

Hear, hear!

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.

A idéia que essas maquinas rodem somente o UCM…

Criado 9 de julho de 2009

Ultima resposta 10 de jul. de 2009

Respostas 5

Participantes 4

5 Respostas

Topicos relacionados