ISTI Open Access

Non capisco il senso di questa segnalazione. Se il war file non fosse esploso, l'applicazione non partirebbe.
Detto questo, vedo varie stranezze nel modo in cui il war è gestito.

• Non c'è l'autounpack configurato su tomcat, quindi dentro webapps il file is.war non è esploso (vale sul vecchio e sul nuovo).
• C'è una directory WEB-INF sotto webapps, con dentro property e classi. Il contenuto è diverso tra vecchio e nuovo, e a occhio quella directory non dovrebbe esistere né da una parte né dall'altra.
• Sul nuovo, il file /var/lib/tomcat_dnet/8080/common/classes/cnr-override.properties contiene

msro.wf.mail.message.baseUrl = http://dnet-openportal.isti.cnr.it:8080/is/mvc/ui

Che magari non influisce, ma credo non sia corretto

• La connessione a mysql non ha TLS abilitato (non riguarda il caso, ma non c'è motivo per non attivare TLS)

Io direi di iniziare con:

• Ripristinare la configurazione del garbage collector (e riportare le modifiche allo heap nel playbook, non è accettabile modificare a mano configurazioni gestite via ansible)
• Attivare lo unpack dei war nella configurazione di tomcat (va messa a True la variabile e aggiunto , autodeploy: '{{ tomcat_m_webapps_autodeploy }}', unpack: '{{ tomcat_m_webapps_unpack }}'a tomcat_m_instances)
• Eliminare da webapps la directory WEB-INF
• Verificare tutti i valori di /var/lib/tomcat_dnet/8080/common/classes/cnr-override.properties

Andrea Dell'Amico wrote in #note-1:

Non capisco il senso di questa segnalazione. Se il war file non fosse esploso, l'applicazione non partirebbe.

Sul filesystem non ci stanno i file del war esploso, e questo associato alla lentezza nelle fasi di ricerca delle risorse mi ha fatto pensare che fosse un problema di deploy dell'applicazione. Come risulta anche dai diversi path delle risorse.

Io direi di iniziare con:

• Eliminare da webapps la directory WEB-INF

FATTO

• Verificare tutti i valori di /var/lib/tomcat_dnet/8080/common/classes/cnr-override.properties

FATTO

FYI: non so se l'incremento dei tempi di startup sia dovuto allo autoUnpack (che è attivo di default sulle installazioni smartgears, ma disattivato in praticamente tutte le installazioni dnet a parte quella di ariadne e poche altre, perché non sono state aggiornate le configurazioni dopo che ho cambiato il default qualche anno fa) o al fix in cnr-override.properties. Se serve si verifica facilmente.

Il fix cnr-override properties non credo sia collegato al problema di lentezza, quella property è un parametro del template di una mail, potrebbe contenere qualsiasi stringa.

Comunque bene così siamo passati da 15 minuti a 24 secondi.

Sto facendo il test, giusto per curiosità, e posso confermare che unpackWars fa la differenza.

Abuso di questo ticket per aggiungere che ho cambiato il playbook in modo da creare utenti non privilegiati per me e Tommaso su tutte le macchine: gli accessi diretti come root dovrebbero essere evitati.