L’installer di Twproject imposta alcune configurazioni di default del web server e dell’uso del database – che potrebbe richiedere una messa a punto per ogni ambiente diverso.
Questa sezione necessita di alcune competenze tecniche di IT.
Uso della memoria Java
Teamwork è un’applicazione Java , e gira su un server web Java – di default Tomcat è affamato di memoria; per fortuna la memoria server al giorno d’oggi è veramente economica.
Il server dove gira Twproject dovrebbe avere almeno 2GB di memoria, dato che Twproject ha bisogno di almeno 1GB.
Se vuoi andare oltre la limitazione di 1GB, non dovresti usare server Windows, dato che questi notoriamente hanno limiti di memoria nell’esecuzione di Java. Usa un server 64 bit Linux e non avrai limitazioni circa la quantità di memoria da destinare a Java.
Va detto comunque che nella maggior parte dei casi d’uso 1GB di memoria per Twproject è più che sufficiente.
Un sintomo tipico che la configurazione della memoria non è a punto è quando ottieni l’errore “java.lang.OutOfMemoryError: Java heap space”.
Il modo migliore per essere sicuri che le modifiche alla configurazione siano state applicate in Twproject è quello di lanciare la pagina “system check” (admin -> system check)e verificare i parametri di memoria lì riportati. Per esempio, prima:
Per fare le modifiche: di seguito le istruzioni per sistemi operativi diversi.
Su un server Windows: apri l’interfaccia dei comandi DOS:
Modifica -XX:MaxPermSize a 384m e
la memoria massima dedicato a 1024MB.
Dopo aver riavviato il servizio Twproject:
Questo è tutto!
Per maggiori informazioni sulla configurazione del servizio di Tomcat: https://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html
Su Linux: apri lo script teamworkLinux.sh, e cambia le impostazioni -Xms128m -Xmx384m con un range superiore.
Su OSX: se si avvia manualmente lo script, aprire lo script teamworkOsx.sh, e cambia le impostazioni -Xms64m -Xmx128m con un range superiore. Se stai lanciando Teamwork come servizio, cambia in [teamwork root folder]/launchdScript.sh la linea “export JAVA_OPTS=-Xmx512M $JAVA_OPTS” (se è #export JAVA_OPTS=-Xmx512M $JAVA_OPTS, elimina il #).
Cache sui permessi
Per limitare il numero di query relative alla sicurezza, molto complesse e frequenti, Twproject gestisce una cache che gli permette di non rieseguire test di sicurezza già eseguiti nell’ultimo “max age”. Modifiche sui ruoli potrebbero quindi avere un effetto leggemrne ritardato ed anzi, nel momento in cui si fa un tuning di essi si consiglia di spegnere la cache.
Abilita altre connessioni database
Di default Twproject usa un pool di connessione al database chiamato Proxool (http://proxool.sourceforge.net/).
Questo pool ha un monitor built-in, che puoi abilitare modificando il web.xml (WEB-INF/web.xml). Aggiungi tra la configurazione dei servlets
<servlet> <servlet-name>proxool</servlet-name> <servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class> </servlet>
E nella mappatura delle servlets
<servlet-mapping> <servlet-name>proxool</servlet-name> <url-pattern>/proxool</url-pattern> </servlet-mapping>
Riavvia Teamwork, e chiama
[your Twproject URL]/proxool
Ottenendo:
Per abilitare altre connessioni db, devi impostare in config.properties la proprietà poolMaxSize:
## connection pooling: optionally set max size poolMaxSize=50
Database in cluster
Twproject usa una semplice connessione JDBC a “un database”. L’entry point può essere certamente in cluster: per questo è necessario fare riferimento alla documentazione specifica del database.
Web server in cluster
Twproject può essere in cluster anche come applicazione: in caso di load balance, le cosiddette “sticky sessions” devono essere abilitate. L’unico conflitto che può verificarsi in caso di applicazione in cluster è nei job programmati. Twproject ha un meccanismo built-in che abilita solo un nodo del cluster per i job programmati. Naturalmente supponiamo che tutti i nodi nell’applicazione cluster puntino alla stessa istanza di entry point del database (eventualmente anche in cluster).