tsp-devel
[Top][All Lists]
Advanced

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

Re: RE : [Tsp-devel] Ptit debriefing necessaire


From: Eric NOULARD
Subject: Re: RE : [Tsp-devel] Ptit debriefing necessaire
Date: Tue, 22 Mar 2005 00:16:29 +0100

En y réfléchissant mieux je pense que ce serait au handler de requête
XML-RPC de "faire ce qu'il faut avec ses fils" pour venir renseigner
les structures actuelles.

En gros c'est au XML-RPC handler de se gérer sa SHM.
Ce qui n'exclut pas de proposer un mini-wrapper pour ça dans
tsp/util ou tsp/core/ipc.

Et a y réfléchir c'est une méthode bien bien louche de faire
mourir le père une fois qu'il a engendré.
On est plus au moyen âge :))
Non sérieusement le père devrait survivre à son fils qui meurt
en fin de gestion de requête charge au père de collecter les
info que son fils aura bien voulu déposer dans une IPC
par exemple une msg queue, plutôt qu'un SHM ce qui permet de
sérialiser gentiment les mises à jour et d'éviter d'impacter
les serveurs multi-thread qui n'ont pas besoin de SHM.

Reste que cette message queue doit-être lu par un thread du process
provider, normalement celui du 'run' sauf que si celui-ci se termine
je vois pas bien qui va collecter les messages.

Votre avis?


Le lundi 21 mars 2005 à 15:59 +0100, TSP a écrit :
> Cela ne risque-t-il pas d'être un peu lourd, tout en shm et un processus à
> chaque requete ?
> Je ne sais pas si la modif de xmlrpc en thread est 
> - facile
> - perenne
> - fiable
> Mais au moins, ce serait + élégant.
> 
> Y++
> 
> >-----Original Message-----
> >From: Frederik Deweerdt [mailto:address@hidden 
> >Sent: Monday, March 21, 2005 8:37 AM
> >To: Devel TSP
> >Subject: Re: [Tsp-devel] Ptit debriefing necessaire
> >
> >
> >Le 14/03/05 22:47 +0100, Eric NOULARD écrivit:
> >> Le lundi 14 mars 2005 à 20:20 +0100, Frederik Deweerdt a écrit :
> >> Ce qui me parait louche dans tes traces ce sont les appels
> >> à TSP_provider_rqh_manager_end , peut-être est-ce par que ta
> >> fonction 'run' se termine après le traitement d'1 requête?
> >Ok, problème, réglé: en fait le serveur HTTP qui dispache les 
> >requêtes fait
> >un fork avec :
> >fils -> RunServer() //Serveur HTTP
> >pere -> exit(0)
> >
> >Le exit(0) déclenchait l'execution des atexit() et lancait le
> >TSP_provider_rqh_manager_end.
> >
> >J'ai résolu le problème de la manière suivante:
> >
> >static clean_exit() {
> >  _exit(0);
> >}
> >
> >static void TSP_rpc_run(TSP_rpc_request_config_t *config)
> >{
> >     atexit(clean_exit);
> >     ...
> >}
> >
> >Mon serveur tourne donc correctement, mais voilà un autre problème:
> >chaque requête xml est traitée par un process différent, ce 
> >qui fait que
> >les données de session (X_session) sont perdues lors d'un nouvel appel:
> >
> >    i/o||tsp_server.c##tsp_request_open_xmlrpc##100: -->IN
> >    i/o||tsp_provider.c##TSP_provider_request_open##247: -->IN
> >  debug||tsp_provider.c##TSP_provider_request_open##265: No 
> >custom args from consumer
> >  debug||tsp_session.c##TSP_add_session##229: I've found room 
> >in X_session_t for the new session. Id in X_session_t is 0, 
> >pid is : 11256
> >   Info||tsp_session.c##TSP_add_session##254: New consumer 
> >connected : channel_id=0, X_session_nb is : 1
> >    i/o||tsp_provider.c##TSP_provider_request_open##299: -->OUT
> >    i/o||tsp_server.c##tsp_request_open_xmlrpc##109: -->OUT
> >    i/o||tsp_server.c##tsp_request_information_xmlrpc##180: -->IN
> >  ERROR||tsp_session.c##TSP_get_session##127: No session found 
> >for channel_id=0, X_session_nb is: 0, pid is 11257
> >  
> >ERROR||tsp_session.c##TSP_session_get_sample_symbol_info_list_b
> >y_channel##331: Unable to get session for channel_id=0
> >  
> >ERROR||tsp_provider.c##TSP_provider_request_information##357: 
> >Function TSP_session_get_sample_symbol_info_list_by_channel failed
> >    i/o||tsp_provider.c##TSP_provider_request_information##367: -->OUT
> >    i/o||tsp_server.c##tsp_request_information_xmlrpc##187: -->OUT
> >
> >Notez comment varie X_session_nb et le pid...
> >
> >Les solutions que je vois seraient:
> >- modifier xmlrpc pour qu'il utilise des threads
> >- mettre toutes les données de session en mémoire partagée
> >
> >J'opterais bien pour la seconde mais peut-être avez vous des 
> >suggestions?
> >A+
> >Fred
> >-- 
> >o----------------------------------------------o
> >| http://open-news.net : l'info alternative    |
> >| Tech - Sciences - Politique - International  |
> >o----------------------------------------------o
> >
> >
> >_______________________________________________
> >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]