Newsgroup: it.comp.java
Titolo: Hot reloading in produzione ?

Salve a tutto il ng,
sottopongo alla vostra attenzione un problema abbastanza annoso che 
periodicamente sul lavoro mi viene riproposto... e che in tutta onestà, pur 
avendoci meditato, non ho ancora capito come risolvere.
Il problema è semplice (ma di difficile soluzione): mi si chiede di 
applicare in qualunque istante delle modifiche al codice J2EE, dove per 
codice J2EE si intendono servlet, ejb, classi di supporto etc, direttamente 
sul server di produzione.
Queste modifiche, di norma, non sono 'dettagli' : si parla di cambiare 
query, modificare la logica di business, aggiungere nuove funzioni... il 
tutto, ovviamente, senza invalidare le sessioni attive, senza arrestare gli 
applicativi etc... in buona sostanza, garantendo una continuità di servizio 
al 100%.
Voi come approccereste il problema ?  Io per mesi mi sono spremuto i pochi 
neuroni sani che mi sono rimasti, ma non sono riuscito a risolvere tutti gli 
aspetti oscuri del problema....
Il guaio - se di guaio vogliamo parlare - è dovuto al fatto che ai miei 
responsabili Java comincia a piacere molto meno perchè richiede tempistiche 
di sviluppo e rigore nel rilascio degli applicativi, mentre attualmente i 
programmi 'tradizionali' (RPG su AS400) consentono ogni "genere di 
violenza", con grande flessibilità nello sviluppo e nel rilascio. Mi 
spiacerebbe, visto che sono un convinto assertore della bontà della 
piattaforma Java proprio in ambito "enterprise", che si pensasse 
(limitatamente dove lavoro io, ovviamente!) che si tratti di una piattaforma 
giocattolo.
Grazie a chiunque vorrà darmi un parere.
Scorpio.

 Voi come approccereste il problema ?
Tenuto conto che si tratta di una richiesta impossibile, il problema
non è più tecnico ma "politico". Quindi l'approccio necessario è
trovare argomentazioni adatte per convincere che bisogna giungere ad un
compromesso.

 
http://csvtosql.sourceforge.net
"Amare le donne intelligenti e' un piacere da pederasta." --
Baudelaire, "Diari intimi"

 linguaggio di scripting giusto ?
No...anche se comprendo la tua domanda: con PHP e simili non è difficile 
gestire un hot deploy, basta cambiare le pagine sotto il naso al web 
server...

 ha scritto nel messaggio 
news:1167388550....@n51g2000cwc.googlegroups.com...
Scorpio ha scritto:


Mmmm... potresti essere più chiaro ? Scusa l'ingenuità ma non capisco come 
la politca possa sopperire ad un problema tecnico...
Tra parentesi, e senza nessuna polemica : mi sembra strano che il problema 
dell'hot deploy non abbia suscitato un maggiore interesse, a parte il tuo 
intervento e quello di Davide Consonni (e vi ringrazio per questo). Delle 
due l'una:
o il problema è mal posto, perchè non è possibile ottenere un hot deploy 
'totale' come  tu scrivi o per altre ragioni che ignoro, e pertanto è 
inutile cercare una soluzione, oppure è un problema che pochi affrontano, e 
quindi dovrei dedurre che sono (o meglio,siamo, considerando il lavoro che 
svolgo con i colleghi) completamente fuori strada nell' utilizzare J2EE.
Eppure mi sembra strano che a nessuno sia mai capitato di dover applicare 
una correzione al volo al codice in produzione.....
Scorpio.

 una correzione al volo al codice in produzione.....
Due possibilità:
1. se la correzione è effettivamente una correzione al volo :-) allora puoi
utilizzare l'hot deploy del debugger, ovvero tendenzialmente puoi cambiare
solo l'implementazione dei metodi ma non le interfacce, vedi i limiti dalla
documentazione.
2. per correzioni "consistenti" devi costruire l'applicazione in modo che
sopporti l'hot deploy e utilizzare un container che soddisfa completamente
le specifiche (visto il mio partito :-) non posso che consigliare jboss
4.0.4+). Alcune indicazioni:
        - mettere in HttpSession SOLO oggetti effettivamente serializzabili
        - non utilizzare EJB Session Stateless (da verificare)
        - fare modifiche compatibili secondo spec serializzazione.
q'pla
        Claudio Vesco

 una correzione al volo al codice in produzione.....
Certo che si, ma la tua richiesta è un po' più articolata :-)
Ripeto, non voglio entrare in merito a cosa ci sia dietro la richiesta 
che ti hanno fatto, ma la vedo come una deregulation della politica di 
deploy e come tale molto pericolosa (soprattutto per i tuoi nervi). Un 
conto è fare una correzione al volo, un'altro conto è garantire che puoi 
fare un qualsiasi rilascio in qualsiasi momento senza impatto per gli 
utenti. A me una richiesta del genere farebbe paura sia dal punto di 
vista tecnico che dal punto di vista organizzativo; dal punto di vista 
tecnico perchè ritengo impossibile garantire a priori che una modifica 
qualsiasi a caldo non abbia impatto sull'utente senza sapere che 
modifica e che operazione sta facendo l'utente; dal punto di vista 
organizzativo perchè mi sembra una richiesta che voglia arrivare a una 
anarchia nel processo di deploy in cui tu devi essere continuamente 
pronto a mettere in linea modifiche, cosa che non ti auguro! :-)

 Claudio Vesco
N
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Scorpio.
Nicola


 ha scritto:
Un'ultima cosa :
Se per caso davvero sei in una situazione strema, stavo pensando cosi' di
getto, ma tutto da verificare e analizzare, di suddividere l'applicazione in
tanti ear , o almeno 2.
Un ear che contiene solo dati stateful/session. Una sorta di server di dati
di memoria.
E un ear che contiene la logica.
A quel punto la logica stateless la puoi cambiare quanto vuoi senza
problemi. E' gia' e' qualcosa e ti costa pochissima fatica :-))
Piu' difficile modificare la pare dati, pens ai ai pojo o a degli entity
bean persistentizzati, e' evidente che vai in "class cast" o "no such
method" se cambi i pojo al volo, a quel punto devi ripiegare su quelle
tecniche professionali di cui ti parlava un altro, ma non oso immaginare con
che che aumento di complessita' dell'applicazione


...incominciando col ringraziarvi per i vostri pareri. Faccio una premessa, 
doverosa: abbiamo, per mille ragioni, come appserver di riferimento 
WebSphere di IBM che, peraltro, secondo me è un prodotto decisamente buono. 
Niente possibilità di lanciarci su Tomcat o JBoss... almeno per il momento, 
a meno che non siano poi gli unici a garantire questo benedetto hot deploy.
Cerco di spiegare qual'è lo scenario tipico in cui lavoriamo: le 
applicazioni Java sono accedute da diverse tipologie di clienti, ciascuno 
dei quali, però, può richiedere che i servizi esposti da queste applicazioni 
siano ampiamente personalizzati. Niente di preoccupante, basta un buon 
factory ed il workflow può essere variato... ma il problema non è tanto 
questo. Supponiamo che un servizio (tipo un order entry) richieda la 
verifica di certi dati su una tabella di database. Alle 10.00 del mattino, 
il cliente A esige che oltre a fare quella verifica, il servizio di 
acquisizione ordini
deve eseguire anche query di controllo su tabelle che il dba ha appena messo 
in linea. Per eseguire questa query, il cliente deve specificare anche un 
valore (che ne so, supponiamo un parametro "data massima prevista di 
consegna", ma sto inventando). Questo parametro salta fuori dal nulla: va 
modificata sia l'interfaccia web che il bravo EJB che implementa il processo 
"Acquisizione Ordine", e, comunque, la logica di business...
Complichiamo le cose: per il passaggio dati tra "strati applicativi" (web ed 
ejb: deployati in EAR diversi, perchè gli stessi servizi / EJB possono 
essere richiamati da nuove applicazioni web o da client) utilizziamo dei 
value object, che sono semplicissimi JavaBean. Però questi JavaBean devono 
essere impacchettati in JAR e caricati dal classloader dell'appserver, 
perchè, altrimenti, WAS si incasina se la stessa versione di classe viene 
passata da un modulo web ad un modulo EJB deployati in due EAR differenti. 
Morale: riavvio del server applicativo necessario per ricaricare le classi.
Ora, se il cliente A vuole un parametro in più, io non posso fare miracoli: 
devo toccare oltre che la logica di business anche il JavaBean che mi 
realizza il value-object corrispondente. Da tempo cerchiamo di limitare i 
Value Object usando il Data Transfer Hashmap pattern per limitare i 
riavvii... ma al di là di tutto, che posso fare quando il cliente A vuole 
SUBITO la modifica ?  'Riaccendo' l' EAR che contiene gli EJB, così gli 
altri clienti sono pronti a picchiarmi ? (ovviamente in senso figurato).
Le modifiche che sono richieste sono raramente di poco conto: fare un 
controllo in più sicuramente non è tecnicamente complicato, ma farlo a caldo 
è un casino, ragazzi... e sinceramente non so che pesci pigliare.
Dove sbaglio ?
Scorpio.

 Stateful ?
Yes... sorry :-)
Vale discorso precedente...

 
http://csvtosql.sourceforge.net
Seconda Legge di Parkinson: Le spese aumentano fino a raggiungere le
entrate.

 
http://csvtosql.sourceforge.net
Lo stoicismo, religione che ha un unico sacramento: il suicidio. --
Baudelaire, "Diari intimi"

 over ?
Soluzione che in effetti ci è stata prospettata da IBM: con una soluzione di 
clustering, in cui l'aggiornamento avverrebbe su un solo nodo, con 
successivo riallineamento a caldo degli altri: a monte dell'appserver, un 
web server a fare da router di richieste verso una delle due istanze...
Non che sia una soluzione non fattibile, questa... che però ovviamente 
lascia perplesso il management, e non so dare torto a chi mi dice: "come mai 
Java comporta tutte queste limitazioni ?". Dal loro punto di vista, il 
minimo che si possa chiedere ad un sistema è quello di continuare a fornire 
un servizio senza interruzione, e la prassi ha dimostrato che sistemi ad 
alta disponibilità possono essere sviluppati in Java. Però, il fatto che ci 
debba essere rigore nell'eseguire il rilascio... beh, non viene digerito.
Scorpio.

 piccola ..
Beh, Davide, possiamo dire tranquillamente che è un fatto assodato che usare 
seriamente Java non è uno scherzo. Un conto è fare tre pagine in PHP, un 
conto è scrivere un'architettura server-side che stia in piedi....
Scorpio. 

 
http://csvtosql.sourceforge.net
E quindi, in nessun senso, la stabilita' e' un motivo per spostarsi su una
nuova versione. Non e' mai un motivo. -- Bill Gates

 
http://csvtosql.sourceforge.net
Un grammo di immagine vale piu' di un chilo di fatti.