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

[Stephane Galles]

Donc plusieurs sujets :
- Je dis oui pour les deux modif ! (en fait effectivement, pour la modif
1 je pense que c'était le comportement désiré, mais mes petits doigts n'ont
pas tapé le code assez vite !)
- Effectivement, le XPath correspondrait exactement à notre besoin (je suis
d'accord qu'avec du regexp + du select sur l'arbo on est au top). Du 
coup on pourrait
transférer en XML les symboles (même si  cela va ajouter de l'overhead, 
parcequ'on
a gagné au niveau de la structure/selection)
- Je ne touche donc pas à la mémoire dispo pour jsynoptic-run
- et puis désolé pour le spam sur mon message d'avant, j'ai un peu 
bégayé avec mon client mail.


Eric NOULARD wrote:

> Le jeudi 10 mars 2005 à 16:38 +0100, TSP a écrit :
>  
>
> > Et il faudrait aussi une API pour recuperer le nombre de symboles coté
> > provider.
> >    
>
> En suivant la bonne idée de Yves et en 
> dehors de la discussion en cours sur la request_info améliorée
> est-ce que vous verriez un inconvénient à rajouter MAINTENANT
> une requête de commande supplémentaire?
>
> TSP_answer_sample_t tsp_request_basic_infos(TSP_request_information_t)
>
> qui ne renseigne que les champs 'basiques' de l'answer_sample :
>
>  
>
> > >         int version_id;
> > >         unsigned int channel_id;
> > >      
>
>         int provider_timeout;
>         int provider_group_number;
>         TSP_sample_symbol_info_list_t symbols;
>  
>
> > >         double base_frequency;
> > > 	int max_period; 
> > > 	int max_client_number; 
> > > 	int current_client_number; 
> > > 	TSP_status_t status;	
> > >      
>
> Eric
>
>
>  
>
> > Maintenant pour gdisp en mode interactif, c'est sur que tu es obligé de
> > passer par le request info. 
> >
> > Tu as essaye un coups de profiler avec gprof pour voir quelle fonction
> > prenait du temps ? C'est sans doute l'appel RPC, mais a verifier. Si oui, la
> > structure est très grosse (en + du nom on a 6 entiers, et un opaque, c'est à
> > dire que l'on double au moins la taille de la structure en moyenne, + les
> > appels à xdr_decode). 
> >
> > On pourrait aussi ne recuperer que la liste des noms dans le request (+
> > infos du provider), et demander les infos pour la liste de symbole qui nous
> > interessent.
> >
> > Y++
> >
> > -----Original Message-----
> > From: Stephane Galles [mailto:address@hidden 
> > Sent: Thursday, March 10, 2005 1:38 PM
> > To: address@hidden
> > Cc: address@hidden
> > Subject: Re: [Tsp-devel] gérer un nombre de symboles...hum...important
> >
> >
> >
> > 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)
> >
> > 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 ?
> >
> > 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
> > _______________________________________________ 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
>
>
>