Newsgroup: it.comp.java
Titolo: java.io.Serializable: qualche spiegazione

Chiedo scusa per la domanda da vero niubbo. Non sono uno sviluppatore
java ma devo implementare un cluster di Application Server usando il
supporto cluster integrato in Tomcat 6.
Nei tutorial che sto studiando, si legge che il primo requisito per
attivare la replicazione all-to-all è:
"All session attributes must implement the java.io.Serializable
interface."
Qualcuno può spiegarmi in modo molto semplice come posso soddisfare
questo requisito su una installazione "pulita" di Tomcat?
Devo aggiungere una sezione in "server.xml"? Oppure nel "web.xml"
delle web apps che voglio replicare? Oppure ancora devo passare
l'opzione all'avvio del server, o ricompilarlo con questa impostazione
attivata?
Insomma, non so proprio dove mettere le mani.
Grazie a tutti.
G

 questo requisito su una installazione "pulita" di Tomcat?
molto banalmente, qualsiasi attributo che scrivi nella sessione deve 
essere di un tipo che implementa l'interfaccia java.io.Serializable. stop.
fra l'altro il problema degli attributi serializzabili ce l'hai solo 
quando la sessione viene serializzata, il che avviene sempre in un 
cluster di tomcat mentre non avviene quasi mai in una installazione 
singola (afaik solo quando salva la sessione su disco durante lo shutdown 
pulito, per recuperarla al successivo startup).
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 questo requisito su una installazione "pulita" di Tomcat?
E' una cosa che dipende dall'applicazione web. Se ti hanno dato una 
applicazione web che non soddisfa quel requisito vuol dire che non 
l'hanno progettata per essere clusterizzabile.
Se gli sviluppatori non l'hanno fatto c'e' poco da fare.
-- 
Andrea Francia
http://www.andreafrancia.it/

On 17 Lug, 11:05, Andrea Francia

Ok, inizia ad essere un po' più chiaro. Aggiungo qualche dettaglio.
Sulle macchine in cluster dovrà girare Axis2 che fornirà un web
service. Il mio obbiettivo è fare in modo che il servizio sia
ridondato (va giù uno dei nodi, il servizio resta in piedi con tutte
le sessioni aggiornate).
Ho già inserito in server.xml di Tomcat la sezione per abilitare il
supporto cluster e dai log non risultano errori, ma non riesco a
capire se la cosa sta funzionando davvero o no.
Perciò ora la mia perplessità è: Axis2 supporta il clustering di
Tomcat nativamente in qualche modo oppure dovranno essere gli
sviluppatori (che sono interni alla mia azienda) a modificare il
codice che stanno scrivendo per renderlo cluster-compliant?
Come posso verificare se la replicazione sta avvenendo correttamente?
Mi sembra strano che non esista un modo "facile" di ridondare un
application server. Per un server in produzione dovrebbe essere una
funzionalità di base.
Grazie
G

 Come posso verificare se la replicazione sta avvenendo correttamente?
allora... per testare la replica, basta fare una paginetta jsp in una 
applicazione web (anche già esistente) che ti mostra l'indirizzo 
dell'host e il contenuto della sessione, poi tiri giù quell'host e dopo 
il reload verifichi che la pagina mostri lo stesso contenuto della 
sessione e (ovviamente) l'address diverso.
questo ti da una ragionevole garanzia che la replica avvenga in modo 
corretto.
per quanto riguarda i web service, se fanno uso della sessione non c'è da 
fare una verifica apposita. sotto questo aspetto si comportano come una 
applicazione web. va da se che un ws, per sua natura, potrebbe non avere 
nessuna necessità di replica delle sessioni, dipende dall'implementazione.


 funzionalità di base.
Probabilmente il modo facile esiste, ma bisogna soddisfare dei requisiti 
per poterlo usare (come ad esempio il fatto che gli elementi della 
session siano serializzabili).
Se i tuoi sviluppatori non ci hanno pensato puoi solo sperare che senza 
saperlo abbiamo soddisfatto i requisiti necessari per implementare il 
modo facile.


 session siano serializzabili).
in realtà non è vero. se l'applicativo non avesse requisiti per la 
clusterizzazione ciò non impedirebbe di clusterizzarlo comunque, senza 
replica delle sessioni. 
nella normale operatività il roundrobin viene fatto solo per le nuove 
sessioni, dopodichè le sessioni vengono servite sempre dallo stesso nodo. 
questo significa che la web application avrebbe problemi solo e soltanto 
in caso di failover del nodo interessato (che si presume abbastanza poco 
frequente) e il problema sarebbe la sola perdita della sessione utente. 
basterebbe fare una valutazione se questa condizione può ritenersi 
accettabile, per una buona parte delle applicazioni web lo è.
