Release Management: Patches em J2EE?

Programação Java
#1

Olá,

Num sistema em ambiente UNIX multiprocessos, é muito fácil aplicar um patch.

O sistema é um grupo de processos que agem em conjunto, se comunicando por pipes, sharedmemory, FIFOs, etc.

Quando um processo (que é um componente do sistema) tem problemas, basta entregar uma nova versão dele.

Como vocês fazem para entregar um patch de uma aplicação J2EE em cima de um Application Server?

A política que vejo sendo seguida é empacotar a aplicação toda (geralmente o EAR) de novo e fazer um hot-deploy, mas os clientes não costumam gostar muito dessa solução.

Alguém tem alguma idéia mágica e limpinha para essa “complexidade acidental” do J2EE?

#2

Por que não, shoes? Você poderia explicar o que eles tem contra para que possamos entender o que você precisa exatamente?

#3

Ok.

Imagina que eu tenho 3 funcionalidades num sistema. Cada processo cudia de uma. Se um patch tem que ser instalado, basta substituir um processo.

A mesma coisa com J2EE, seja qual sigla ou framework. Eu tenho que parar tudo para um hot deploy que, dependendo do servidor, não é tão “hot” assim (ok, pode-se dizer que é uma batata quente :slight_smile: ).

Agora multiplica o número de funcionalidades por… uhm… 20, e um sistema que pode ficar um tempo mínimo fora do ar (SLA).

Para instalar o “patch” da funcionalidade X (e nem sempre é manutenção coirretiva, pdoe ser uma mudança qualquer que o cliente pediu), o sistema TODO para. Pelo menos isso que eu experimento com JBoss 3.2.x. A Janela é mínima, mas como falei cada segundo é muito caro, e se aidna fosse só a funcionaldiade consertada a ser parada, estava tudo bem.

Eu acredito que a questão é mais cultural,e que J2EE em si não foi feito pensando nisso, mas de repente alguém tem uma boa idéia :slight_smile:

#4

Agora ficou mais claro. Fragmentar sua aplicação em unidades de deployment menores não ajuda nesse seu caso? Se não, por quê?

#5

Imagina que eu tenho um sistema que gerencia uma fábrica de carros.

Eu tenho um componente que gerencia o estoque, um componente que gerencia a linha de montagem e um que gerencia a distribuição.

O que você está sugeridno é não usar uma aplicação só com tudo, ams sim um conjuntod e três aplicações? Isso seria performático :roll:

#6

Sim e Deus sabe :slight_smile: O único jeito de saber é testando.

#7

Olá

[color=brown]Esta mensagem foi reescrita porque apertei uma merda no meu teclado e a máquina rebootou e eu perdi trabalho além de um monte de janelas abertas. :twisted:
Bem, vamos ver se consigo reproduzir pelo menos a idéia do que tinha escrito antes.[/color]

O normal que dá menos trabalho e mais rápido é fazer exatamente como você falou. Sei que a sugestão do mister_m de separar as aplicações ou fragmentar as atualizações pode ser uma mão na roda mas provavelmente tem muitas coisas que talvez precisem entrar no ar juntas por estarem interligadas. Imagino que por contrato vocês tenham que concluir alguma etapa para talvez até receber a grana a ela correspondente e que a fragmentação pode significar uma postergação da entrega.

Questões de SLA são eminentemente políticas. SLA é um acordo. Se o cliente se mostra inflexível seu prejuízo talvez não seja coberto por multas que as vezes levam anos de discussão judicial. Já tive por quase 2 anos convívio com uma enorme empresa de serviços acostumada a levar gigantescas multas de mastodônticos clientes. Ela nunca pagou um centavo destas multas. Sempre negociou e conseguiu convencer os clientes (apesar de alguns clientes darem murros na mesa em reuniões).

Minha sugestão é que envolva o cliente neste problema. Tentem convence-lo de que parando em determinados momentos para atualizar o ear o prejuízo será menor do que ficar sem as novas facilidades. Caso o cliente se mostre inflexível, bem se eu tivesse resposta para esta negociação eu seria diretor de empresa e não apenas desenvolvedor. Seu diretor deve saber resolver este pepino.

Que N.Sra dos Prazos Descumpridos lhe deem uma boa hora e iluminem seu cliente. E que Murphy esteja na hora do lanche!

[]s
Luca

#8

Pois é… são paradigmas estruturais (!) diferentes…

J2EE por incrível que pareça é tendenciosa para um arquitetura monolítica nesse aspecto.

Nós temos carregamento dinâmico, compilação incremental, componentes e objetos, mas na hora de atualizar só uma parte do todo que é um sistema, temos que afetar o funcionamento normal de todas as partes :frowning:

#9

[quote=pcalcado]
O que você está sugeridno é não usar uma aplicação só com tudo, ams sim um conjuntod e três aplicações? Isso seria performático :roll:[/quote]

Não acho que você vai ter problemas de performance, mas só fazendo stress test mesmo para confirmar.

Cuidado apenas com algumas surpresas que você pode ter em relação a classpath e visibilidade de classes, dependendo do AS que você estiver utilizando.

O problema que vejo é que apesar de você ganhar mais flexibilidade na hora de aplicar um patch em apenas 1 componente da sua solução, você vai deixar de ter 1 aplicação para gerenciar e vai passar a ter 20 componentes deployados independentes …

O pessoal de suporte/produção vai adorar! :smiley:

#10

Separar em varias aplicações menores tem seus problemas. Mas nada que o super UCL do jboss não ajude (a piorar ainda mais).

Se você usar isolamento completo entre os EARzinhos, vai ter toneladas de dependencias sendo carregadas em classloaders diferentes, isso vai custar muita memoria e alguma performance.

Se você usar algum classloader hack do teu container, aka jboss UCL, vai ser bem trabalhoso quando um EAR que publica dependencias para outros precisar de redeploy. Como solução proprietaria você pode usar os MBeans do jboss para declarar esse tipo de dependencia que ele ajuda um pouquinho.

Outra solução, mais radical, é usar um container feito para esse tipo de cenario, onde temos módulos entrando e saindo em runtime, com suas dependencias sendo geridas corretamente pelo container. Essa solução chamasse OSGI, acho que o futuro do J2EE está ai. Bundles OSGI são muito mais amigaveis ao hot deployment que um EAR.

Finalmente, hot deployment é uma falacia tão grande quanto WORA para J2ME (100 dispositivos, pelo menos 90 versões). Oroblemas de class leakage por causa do J2SE ou libs que ficam em classloaders mais privilegiados do container é muito comum. Rapidinha… Ate qual versão do J2SE a classe java.beans.Introstector causava class leakage?

#11

Parou? :mrgreen:

#12

Olá

Continuo assustado! O post do louds para mim é muito avançado para o dia a dia de uma empresa que nem sempre tem tanto tempo assim para pesquisar e testar soluções inovadoras. Afinal nem todas as empresas tem gente do quilate do louds :slight_smile:

Ainda acho que se deve fazer o feijão com arroz do atual estado da arte que é o deployment do ear. Se pode melhorar um pouquinho isto separando uma coisa ou outra mas eu não faria nada que me desse muito trabalho porque poderia introduzir novas incertezas ao projeto.

Para mim o melhor caminho ainda é o de levantar uma bandeirinha de atenção e negociar com o cliente uma solução. Agora meu conselho não mais do meu lado desenvolvedor e sim da minha formação de engenheiro com mais de 10 anos trabalhando em empreiteira de grande porte e com clientes enormes, inclusive fora do país. No ambiente de engenharia este tipo de acordo no meio da obra é comum. Já estou até imaginando o diálogo quando ambas as partes sentam-se na mesa para discutir a situação de fato:
[color=darkblue]
Cliente: Kolé mermão, isto de fazer atualizações a quente devia ter sido previsto!

Fornecedor: É, mas no contrato não previa aquela coisa que fiz para ti sem cobrar nada.

Cliente: PQP, eu vou entrar na justiça! Vocês vão me pagar tim tim por tim tim o que está no SLA.

Advogado do cliente sussurra: Psss, mas e no meio tempo fica tudo parado? A indenização pode demorar para sair!

Cliente dando soco na mesa: Pô, vocês são uns merdas. Toda vez é a mesma coisa. desta vez vou concordar mas na próxima vocês estão ferrados.
[/color]
Uma hora depois na mesa do restaurante que o fornecedor paga o almoço para o cliente.
[color=darkblue]
Cliente saboreando vinho: Mas será que vai dar tudo certo mesmo?

Fornecedor: Tranquilo! Já agimos assim com muitos clientes.

Cliente comendo profiterolis: Então está bom, vamos combinar o melhor momento para parar tudo e deixar a equipe de suporte de plantão.
[/color]
Uma hora depois na sala do diretor do fornecedor.
[color=darkblue]
Diretor: Legal, agora é só fazer a instalação hoje de madrugada e na segunda feira que vem mandar a fatura.

Gerente: Aquele almoço com vinho chileno ficou bem mais barato do que pagar hora extra ao merda do Philippe que ia ficar 2 semanas até altas horas para desenvolver, instalar, testar e homologar o pitaco deste tal de louds guru do GUJ.
[/color]

:lol:

[]s
Luca

#13

Sim e não. Esse tipo de erro é muito dificil de reproduzir. Fiz alguns micro testes contra a 1.4.2_02/3 e não estava mais vazando memoria.

Mas sob carga - stress test de um APP J2EE, o GC acaba fazendo 1 zilhão de minor colections, só nos 47 do segundo tempo e depois de alguns fulll gc de 5 dias ele mata todas Soft/WeakRefs e limpa a Perm Gen e Old Gen dos classloaders mortos e seu entulho.

#14