[Partecipa-net-devel] BUGFIX: implementazione redirect + fork per operazioni lunghe

[Enrico A. <an...@na...>]

Ho aggiornato il cvs per un problema che si era manifestato presso il =20
Comune di Modena dove, essendoci molti iscritti, quando si eseguivano =20
certe statistiche (in particolare la statistica utenti) si verificava =20
un timeout lato server in quanto l'esecuzione in linea dello script =20
richiedeva piu' di 300 secondi (che e' il timeout di default di apache)

Questo problema ne espone uno molto piu' generico che ho dovuto =20
risolvere per forza: qualsiasi operazione in Partecipa.base viene =20
eseguita in linea, e se supera il timeout di apache puo' incorrerre =20
nello stesso problema; avevo gia' riscontrato un problema simile =20
nell'invio in massa delle email per i sondaggi (ora risolto), ma in =20
quel caso ho preferito optare per una soluzione specifica perche' la =20
mail aveva bisogno di sicurezze aggiuntive e soprattutto non c'era la =20
necessita' di un feedback immediato all'utente, come nel caso delle =20
statistiche.
Per questi motivi ho dovuto interrompere il resto dello sviluppo per =20
concentrarmi su questa cosa, che mi ha richiesto parecchio tempo =20
perche' comporta varie modifiche al componente principale di tutto =20
Partecipa.net, cioe' il cgi-bin unox1 (normalmente installato in =20
/var/www/cgi-bin/partecipa.base/unox1) che esegue tutte le funzioni =20
condivise dell'applicativo (template, autorizzazioni, database etc) e =20
che lancia le procedure esterne richieste (i comandi .uxu).
Inoltre la soluzione doveva essere piu' generica possibile, ed =20
implementabile con le minori modifiche possibili ai moduli che via via =20
presentassero questo problema di timeout.

La soluzione che ho scelto e' la seguente: implementare nel cgi-bin =20
unox1 un redirect comandato da parametri cgi, che rimadasse ad una =20
pagina intermedia di attesa, generica, che a sua volta effettuasse un =20
refresh periodico per mostrare l'avanzamento dell'elaborazione, ed =20
alla fine di questa elaborazione presentasse all'utente un link per =20
visualizzare il risultato dell'elaborazione.
Inoltre a fronte di questo redirect sono stato costretto a lanciare i =20
comandi .uxu "pesanti" con un fork, in quanto senza questo espediente =20
l'elaborazione rimarrebbe in linea e si incapperebbe nello stesso =20
errore di timeout, perche' il wrapper (unox1) attende l'uscita dal =20
comando .uxu per chiudere la sessione http.

L'aggiornamento che ho appena fatto sul cvs comprende appunto le =20
modifiche al cgi-bin unox1, la form di attesa, la funzione per =20
aggiornare lo stato corrente dell'elaborazione e le modifiche alla =20
form e al comando di statistiche utenti.
Per ora sembra funzionare egregiamente nel mio ambiente di test; =20
lascio da parte l'implementazione di questo nuovo sistema nei restanti =20
moduli statistici per permettervi di testare questo codice in ambienti =20
diversi dal mio: se il riscontro sara' positivo, o in alternativa se =20
fra un po' di tempo non avro' nessun riscontro procedero' alla =20
modifica a tappeto di tutti i moduli statistici .

I files da aggiornare tramite cvs sono:
./src/common/lib/functions/misc-utils.pl
./src/web-interfaces/pub/templates/head_refresh.template
./src/web-interfaces/pub/templates/wait_page.template
./src/web-interfaces/pub/templates/corpo_wait_page.template
./src/web-interfaces/pub/templates/top_refresh_personal.template
./src/web-interfaces/pub/unox1
./src/web-interfaces/pub/forms/statistiche_utenti.form
./src/web-interfaces/pub/cmds/adminStatUsers.uxu

Come sempre vi consiglio di non testare il codice su macchine di =20
produzione e comunque di fare un backup dei files originali in modo da =20
poter tornare indietro in caso di problemi.