[Fusioninventory-devel] [Perl] Acces concurrent à un fichier de log

dimitry ernot dimitry.ernot at gmail.com
Thu Oct 14 13:50:20 UTC 2010


Bonjour.

J'ai été confronté au même problème, il n'y a pas si longtemps. Je l'ai
résolu en attribuant des time-slots à mes scripts. C'est à dire que mes
scripts ne pouvaient accéder au fichier de log que durant une période donnée
(1s toutes les 1,5s).
Pour ma défense, mes scripts prenaient entre 8 et 12 heures à l'exécution et
je n'étais pas à 10 minutes près.


Le 13 octobre 2010 10:56, Guillaume Rousse <Guillaume.Rousse at inria.fr> a
écrit :

> Le 13/10/2010 09:32, Kevin Hinault a écrit :
> > Le 11 octobre 2010 23:57, Guillaume Rousse <Guillaume.Rousse at inria.fr> a
> écrit :
> >> Bonjour.
> >>
> >>
> >> C'est joli tout plein, mais voilà, l'agent est relativement parallélisé.
> >> Et comme on ne se refuse rien, il utilise à la fois du multi-thread
> >> (pour gérer son interface web, si nécessaire) et du multi-processus
> >> (pour lancer ses taches, s'il tourne sous forme de démon). Et ce genre
> >> de situations peut aboutir à deux problèmes:
> >> - une corruption du fichier, pour le cas d'écriture simultanée
> >> - un mauvais fonctionnement du mécanisme de surveillance automatique de
> >> la taille du fichier, avec apparement un intervenant qui efface un
> >> fichier, tandis qu'un autre garde le descripteur correspondant à
> >> l'ancien... (http://forge.fusioninventory.org/issues/406)
> >
> > D'habitude je lis les messages de la liste plutôt que d'y répondre car
> > ce que j'y vois est d'un niveau bien supérieur au moins mais pour une
> > fois j'ai l'impression de pouvoir répondre. Je suis peut être à côté
> > de la plaque (tu jugeras) mais pour gérer les accès concurrents
> > multi-thread, multi-processus, ne serait-il pas plus efficient de les
> > rediriger vers un processus type démon qui ne servirait qu'à ça ? Ca
> > demande de mettre une communication client/serveur mais dans ce cas,
> > seul le serveur aurait le loisir de logger les messages et comme il
> > serait assez simple, il serait aussi robuste aux plantages.
> Tu as parfaitement raison. Le seul problème, c'est que ca ne correspond
> à la contrainte 'bidouille temporaire, même si totalement inefficace, en
> attendant un vrai changement d'architecture'...
>
> --
> BOFH excuse #299:
>
> The data on your hard drive is out of balance.
>
>
> _______________________________________________
> Perl mailing list
> Perl at mongueurs.net
> http://listes.mongueurs.net/mailman/listinfo/perl
>
>


-- 
dimitry Ernot
membre du projet JNS
http://jacknsee.sourceforge.net/
membre du projet Ktopsy
http://sourceforge.net/projects/ktopsy/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/fusioninventory-devel/attachments/20101014/202a076a/attachment.htm>


More information about the Fusioninventory-devel mailing list