Quais são as melhores práticas em relação a várias JVMs em um servidor?

Question

Muitos produtos de terceiros exigem uma versão específica do JRE ou do JDK e muitos dos nossos servidores têm várias funções. As equipes de aplicativos argumentam que não devem se importar onde o Java está instalado. A maioria dos aplicativos simplesmente depende de variáveis de ambiente (ou qualquer que seja o Java que esteja por aí), mas as equipes que precisam de versões específicas precisam ser informadas sobre onde encontrar sua versão específica. Eu não gosto do fato de que agora eu não posso relocar uma JVM sem visitar todos os aplicativos que podem usá-la. A resposta óbvia é criar um programa que esconda os detalhes deles e exponha o local por meio de uma API. Essa solução exigiria que cada aplicativo Java fosse incluído em algum script perguntando sobre o ambiente.

Eu não gosto de complexidade desnecessária ou reinvento a roda. Existe alguma prática padrão, recurso embutido em Java ou solução óbvia que estou perdendo?

O que eu pensei é que cada aplicativo gerencie um link em seu caminho para apontar para o Java que ele quer, mas eu ainda precisaria dizer onde ele está.

    

Answer 1

Idealmente, você precisa definir duas variáveis de ambiente:

export JAVA_HOME=/java/location
export PATH=$JAVA_HOME/bin:$PATH

Você pode criar scripts diferentes para iniciar os vários programas e definir essas variáveis de maneira diferente em cada caso. Ou você pode configurar cada aplicativo para iniciar com uma conta de usuário diferente e definir essas variáveis no script de inicialização apropriado dos usuários.

$ JAVA_HOME / bin precisa vir primeiro no PATH para evitar quaisquer outros binários java no caminho padrão sendo executado.

    

Answer 2

Virtualização é como lidamos com isso onde eu trabalho.

update - Desculpe se eu não estava claro - nós hospedamos cada aplicativo em seu próprio servidor virtual com apenas a versão da JVM que ele requer

    

Answer 3

A abordagem do link simbólico é boa, mas considere que você pode não querer atualizar o jvm para todos os aplicativos de uma só vez.

Se você estiver lidando com aplicativos de missão crítica, convém ter uma JVM por aplicativo ou fazer com que cada aplicativo aponte diretamente para uma versão específica da JVM.

Por exemplo, onde eu trabalho, há um aplicativo (chamado de A) que funciona especificamente e foi testado em relação a um JDK e versão específicos (JDK 1.5.0_03), sabe-se que as versões posteriores o quebram.

Se o aplicativo A e outro aplicativo B apontassem para um link simbólico chamado java-5, e quando o BI do aplicativo fosse implementado e decidisse atualizar o java-5 para apontar para o JDK 1.5.0_14, o aplicativo A seria interrompido.

    

Answer 4

Como mencionado em "Qual é a melhor prática para lidar com informações específicas do sistema sob controle de versão?", o caminho de uma JVM pode fazer parte de uma fase de desvabilização.
Ou seja seu arquivo de configuração pode ser reescrito em:

• tempo de implantação, substituindo algumas variáveis por valores específicos do ambiente
• tempo de execução (no início), substituindo algumas outras variáveis por valores específicos da sessão.

Isso significa que, apenas no início do aplicativo, colocamos uma consulta em um banco de dados que contém valores que podem mudar de uma sessão para outra. O caminho final da JVM é um deles.
A consulta é baseada no nome do servidor (ou pool de servidores) e no nome do programa.

    

Answer 5

Em sistemas baseados em * nix você pode usar links suaves. Em seguida, basta escrever seu script de inicialização para usar a versão menos específica que ele preferir. JRE_HOME = / usr / lib / jre / java-5

/usr/lib/jre/...

java -> java-5
java-4 -> java-4-sun
java-5 -> java-5-sun
java-6 -> java-6-sun

java-4-sun -> java-4-sun-1.4.0.0
java-5-sun -> java-5-sun-1.5.0.14
java-6-sun -> java-6-sun-1.6.0.10

java-4-sun-1.4.0.1
java-5-sun-1.5.0.12
java-5-sun-1.5.0.14
java-6-sun-1.6.0.10

Este é o método usado por muitos sistemas baseados em Linux. veja / etc / alternitives e / usr / lib / jre para exemplos.

No Windows, você pode usar variáveis de ambiente para fazer algo semelhante. Em seguida, seu script de inicialização pode "definir JRE_HOME =% JAVA_5%".

    

Answer 6

As equipes de aplicativos não podem ter os dois lados.

Se o aplicativo suportar apenas uma versão do JRE, ele deverá ser enviado com ele. Ele deve ser instalado ao lado do aplicativo.

Não vejo por que eles gostariam de outra forma. Fazer isso desta maneira garante que a versão exata do JRE em que eles testaram seu aplicativo com seja a mesma que você está implantando na produção. Pensar que você deveria "não se importar" com a JVM é um bom ideal quando você está na escola e Java é "escreva uma vez, rode em qualquer lugar". Mas, francamente, essa visão não se alinha com o mundo real, onde Java é, de fato, "escreva uma vez, teste em todos os lugares".

Seria um pesadelo de suporte para a equipe de aplicativos ter que se preocupar com problemas específicos da JVM. Eliminar essa incerteza, sugá-lo e usar uma JVM por aplicativo. O espaço em disco é barato.

    

Answer 7

Nós apenas usamos links simbólicos para as versões que queremos usar. Temos várias máquinas que possuem o java instalado em diferentes locais e o aplicativo não precisa saber onde estão em caixas diferentes.

Outra opção é usar o java webstart para seus aplicativos. Nesse caso, ele baixará e instalará a versão correta, se você não a tiver.

    

Answer 8

Eu coloquei tudo em / opt / java-version usando o download extraído da Sun (mantendo o nome do diretório padrão). Os aplicativos geralmente são executados como seu próprio usuário e são iniciados e interrompidos por meio de um script de inicialização que define todas as variáveis para esse aplicativo, incluindo $ JAVA_HOME.

Se eu tenho um aplicativo, quero sempre usar a instalação "atual" em / opt. Eu crio links simbólicos em / opt e faço o script de inicialização apontar para esse link simbólico. O link simbólico então é ajustado quando um novo tempo de execução Java é instalado.