tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] gérer un nombre de symboles...hum...important


From: Eric NOULARD
Subject: Re: [Tsp-devel] gérer un nombre de symboles...hum...important
Date: Thu, 10 Mar 2005 19:50:56 +0100



Le jeudi 10 mars 2005 à 07:37 -0500, Stephane Galles a écrit :
> Hum...A la décharge de jSynoptic, je pense qu'il suffit juste
> d'augmenter la taille de mémoire disponible dans Java au lancement
> (c'est une sécurité pour éviter qu'un process ne gèle une machine)

Euh je sais qu'on peut lui passer le -mx ...
mais comme je l'ai dit dans un mail précédent
c'est pas tellement un pb de jsynoptic c'est plutôt
un pb de conception de la request_infos...

A priori je trouve que la solution de limitation mémoire de Java
est une bonne chose même si elle est quelque peu redondante du 'ulimit'
sous Unix.

> 
> Actuellement le lancement par 'ant jsynoptic-run' se fait avec la taille
> par défaut. Mais dés qu'on fait des choses un peu osées, il faut la 
> modifier.
> 
> Pas le temps là, mais je fais cela ce soir  (donc cette nuit...)
> 
> A vu de nez, quand tu a lancé tsp_gdips+ la taille mémoire de ton PC
> a chuté de combien ?

Sinon j'ai fait environ +200Mo  :))
Ne fait pas la modif,
ajoute peut-être un commentaire dans le build.xml pour dire
où et comment le faire en cas de besoin.

Mais ça me parait sain de ne pas autoriser un process
qui prendrait d'un coup 200Mo de RAM :))

> 
> Néamoins, effectivement le fichier de conf xml s'impose de plus en plus.
> 
> Steph
> 
> 
> address@hidden wrote:
> 
> >Je joins à mon mail un petit screenshot
> >d'un TSP gdisp+ qui a mis environ 1 minute à démarrer,
> >je vous laisse chercher pourquoi...
> >
> >A noter qu'en voulant connecter jsynoptic à ce 
> >provider TSP OPERATIONNEL (bb_provider), 
> >il m'a gentiment explosé à la tronche--> "Out of Memory".
> >
> >Ce n'est pas le cas de tsp_gdisp+ qui a juste "souffert"
> >pour démarrer.
> >
> >A noter que même si certain consumer ont souffert le
> >provider lui semblait peinard :))
> >Je resalue stéphane pour ça.
> >
> >Donc il faut ABSOLUMENT prévoir que:
> >********************************************
> >les consumers ne fasse PAS SYSTEMATIQUEMENT
> >une requete "tsp_request_infos".
> >********************************************
> >
> >je vois 2 solutions à ça,
> >
> >1) La première est en cours fichier de conf.
> >   (sauf que dans le cas de jsynoptic ça marche pas
> >    aujourd'hui parce qu'on ne sait pas créer un 
> >    fichier de conf sans se connecter à un provider
> >    et donc envoyer l'infâme request_infos...)
> >
> >2) La deuxième c'est qu'on implemente une API
> >   requests_infos_limited qui renvoie un nombre limités
> >   de symboles qui correspondent à un pattern (regexp)
> >   on peut/doit imaginer un moyen de les découvrir
> >   tous mais par petit bout...
> >
> >Voila quand on laisse des utilisateurs mettre ...
> >autant de symboles qui veulent ce que ça donne :))
> >
> >Eric
> >
> >
> >  
> >
> >
> > ------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Tsp-devel mailing list
> >address@hidden
> >http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >  
> >
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]