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

[Eric NOULARD]

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