[Obm] OPUSH/jetty dans la version 2.4.0.1

[Vince]

Bonjour,

Nous rencontrons les mêmes problèmes. (même message d'erreur)

Merci pour le tuyau pour augmenter la mémoire allouée. ;-)

Par contre, j'ai planifié une tache "cron" pour redémarrer différents 
services chaque nuit pour pouvoir avoir une continuité de service 
"correcte" pour nos utilisateurs.
/etc/init.d/opush restart
/etc/init.d/obm-tomcat restart
/etc/init.d/obm-locator restart

Si je ne redémarre pas ces services-là, j'ai le même problème et 
impossible de se connecter avec opush et également il y a des problèmes 
avec la synchro du connecteur OBM/Thunderbird, notamment pour les envoi 
d'invitation qui ne sont alors plus.

CDT

Vincent

Le 12/04/2012 17:20, Couturie Laure-Amélie a écrit :
> Bonjour,
>
> Nous venons de faire l'upgrade de notre serveur obm en version 2.4.0.1.
> Il est en exploitation depuis aout 2010 en version 2.3.12 avec environ
> 450 utilisateurs satisfaits de ce service.
> Tout s'est plutôt bien passé, nous en avons profité pour installer
> Roundcube qui fonctionne bien.
>
> Nous rencontrons un problème de mémoire avec  opush via jetty et le
> process java jsvc.
> Nous avons augmenté la taille de ce process à 4GO avec l'argument
> -Xmx4096m (le défaut était de 512m):
> # ps -ef|grep jsvc
> root       930 25026  0 17:03 pts/1    00:00:00 grep jsvc
> root     25007     1  0 15:48 ?        00:00:00 /usr/bin/jsvc -user
> jetty -cp
> /usr/share/java/commons-daemon.jar:/usr/share/jetty/start.jar:/usr/share/jetty/start-daemon.jar:/usr/lib/jvm/java-6-sun/lib/tools.jar
> -outfile /var/log/jetty/out.log -errfile /var/log/jetty/out.log -pidfile
> /var/run/jetty.pid -Xmx4096m -Djava.awt.headless=true
> -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/var/cache/jetty/data
> -Djava.library.path=/usr/lib -DSTART=/etc/jetty/start.config
> -Djetty.home=/usr/share/jetty -Djetty.logs=/var/log/jetty
> -Djetty.host=0.0.0.0 -Djetty.port=8082
> org.mortbay.jetty.start.daemon.Bootstrap /etc/jetty/jetty-logging.xml
> /etc/jetty/jetty.xml /etc/jetty/jetty-shared-webapps.xml
> jetty    25008 25007 99 15:48 ?        02:01:20 /usr/bin/jsvc -user
> jetty -cp
> /usr/share/java/commons-daemon.jar:/usr/share/jetty/start.jar:/usr/share/jetty/start-daemon.jar:/usr/lib/jvm/java-6-sun/lib/tools.jar
> -outfile /var/log/jetty/out.log -errfile /var/log/jetty/out.log -pidfile
> /var/run/jetty.pid -Xmx4096m -Djava.awt.headless=true
> -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/var/cache/jetty/data
> -Djava.library.path=/usr/lib -DSTART=/etc/jetty/start.config
> -Djetty.home=/usr/share/jetty -Djetty.logs=/var/log/jetty
> -Djetty.host=0.0.0.0 -Djetty.port=8082
> org.mortbay.jetty.start.daemon.Bootstrap /etc/jetty/jetty-logging.xml
> /etc/jetty/jetty.xml /etc/jetty/jetty-shared-webapps.xml
>
> En surveillant le démon par top, on voit sa taille mémoire augmenter et
> le service finit par se planter sur des erreurs de type (opush.log):
> 17:21:21.921 [ERROR] {o.o.a.t.TransactionalInterceptor}
> [t/c/r/]:transaction was rollback
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 17:21:22.005 [ERROR] {o.o.a.t.TransactionalInterceptor} [t/c/r/]:GC
> overhead limit exceeded
> java.lang.OutOfMemoryError: GC overhead limit exceeded
>
> Quelqu'un a t il rencontré le même problème? A t on un problème de
> paramétrage? (nous avons environ 70 périphériques mobiles déclarés)
>
> Merci d'avance. Cordialement.
>