Discussion :

[elfasys]

Bonjour

J'ai chez un client une application (à problèmes) nommée APPLI : des tâches lancées périodiquement (toutes les secondes environ) s'arrêtent d'une manière qui semble aléatoire toutes les semaines environ.

Après avoir renoncé à trouver la cause du problème (malgré votre aide, dans d'autres posts), je voudrais simplement que ce défaut soit masqué.

J'ai pensé :

1. faire écrire dans un fichier texte l'heure système par la routine qui s'arrête (la routine à tester de APPLI)

2. faire une mini-application (ou un service) qui relit ce fichier
a- cette appli vérifie que, quand l'application APPLI est lancée, la date enregistrée évolue.
b- si elle n'évolue pas, cela veut dire que APPLI est plantée
c- faire alors ExeTermine(APPLI) suivi de LanceAppli(APPLI) (qui ressemblent fort au TASKKILL et CALL des commandes DOC)

Ma question :

Est ce que APPLI sera systématiquement tuée quelle que soit la cause de son plantage ?
Est ce que les threads lancés dans APPLI seront eux-aussi arrêtés ?
Est ce qu'il faut introduire une tempo entre les deux ordres (entre arrêt et relance) ?
Est ce que ça marchera dans tous les cas ?

Toutes ces questions parce qu'il m'est difficile de recréer un arrêt pour essai, vu que je ne sais pas pourquoi APPLI s'arrête... et que c'est installé chez un client.

Quelqu'un a cette expérience ?

Merci

[DelphiManiac]

Avant de répondre à la question, j'aurais 2 petites remarques :

A priori le ExeTermine devrait tuer l'ensemble, c'est à dire la tâche et les thread. Par contre :
1) Je passerais par ExeTermine(<Identificateur de processus>) avec l'id du process à tuer.
2) Je ne passerais pas par un fichier pour tracker la tâche, mais par un socket tcp entre les 2. Le fichier risque de poser des problèmes de concurrence d'accès.
3) Je créerais un service pour surveiller la tâche.

Pour les questions :

Est ce qu'il faut introduire une tempo entre les deux ordres (entre arrêt et relance) ?

Difficille à dire ne connaissant pas la raison du plantage, il peut y avoir un délai avant que l'appli planté ne libère toutes les ressources utilisées.

Est ce que ça marchera dans tous les cas ?

Faudra tester ^^


Mais avant tout, à ta place, je continuerai à essayer de comprendre pourquoi l'appli plante !!!

[elfasys]

Mais avant tout, à ta place, je continuerai à essayer de comprendre pourquoi l'appli plante !!!

Oui, je suis bien d'accord. Mais j'ai essayé (depuis plus d'un an) tout ce qui m'est passé par la tête (et j'ai de l'imagination...)

Quand à la relance automatique, je m'en sort bien en utilisant un signal (ouvert par Appli quand elle tourne) au lieu d'un fichier, mais si j'essaye d'exploiter ce signal dans un service, j'ai des problèmes :

L'instruction ExeTermine(Appli) tue bien l'application (et apparemment tous les threads qu'elle a lancé) : OK
Le problème : LanceAppli(Appli) ne la relance pas en tant qu'application, mais sans doute comme un service (je vois dans le gestionnaire de tâche le processus Appli qui apparaît, mais l'application reste invisible)

J'ai essayé aussi d'utiliser un assemblage .NET (conseil PCSoft), mais cela semble bien performant pour ce que je veux faire (et nécessite un savoir-faire que je n'ai pas)

Ma question : peut-on lancer une application à partir d'un service (avec des instructions Windev simples)

Sinon, je laisse tomber le service et j'utilise une appli normale...

[OnePoint]

Bonjour,

Ma question : peut-on lancer une application à partir d'un service (avec des instructions Windev simples)

Sinon, je laisse tomber le service et j'utilise une appli normale...

Je ne dirai pas catégoriquement que c'est impossible.

J'imagine qu'avec Windows il est possible à un processus service de s'attacher à un bureau utilisateur pour y lancer un processus.
Mais c'est sûrement délicat de maîtriser l'ensemble des autorisations, et puis il faut totalement maîtriser l'API Windows pour les objets Stations et Desktop.
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Aussi, il est sûrement plus réaliste de programmer un lanceur qui démarre le processus "fragile", reste en tâche de fond, surveille l'activité du processus (exemple via des signaux), et en cas d'inactivité "douteuse", supprime le processus, puis relance une nouvelle instance, etc.

Bien sûr il faut prévoir l'arrêt normal du processus surveillé.

Quand à la relance automatique, je m'en sort bien en utilisant un signal (ouvert par Appli quand elle tourne) au lieu d'un fichier, mais si j'essaye d'exploiter ce signal dans un service, j'ai des problèmes :

Je trouve aussi que l'utilisation d'un signal est bien adaptée pour surveiller l'activité d'un processus.

Bon courage !

[elfasys]

J'ai fait cette surveillance sous forme d'un petit projet paramétrable (un peu)
Cela semble fonctionner sans le moindre problème (au moins sous XP et Seven).

A votre avis, est ce que ce code peut intéresser quelqu'un ?

Si oui, sous quelle forme faut-il le communiquer ?

[jdsetls]

Bonjour,

Après avoir lu tous les posts, je me pose la question suivante :

Que se passerait-il si tu remplaçais les éventuelles données coupables en entrée par des variants dans ton pgm qui plante ?

Quitte à retyper en sortie...

Simple idée parmi d'autres...

Bien cordialement,

Jacques De Schryver

[elfasys]

Bonjour,
Que se passerait-il si tu remplaçais les éventuelles données coupables en entrée par des variants dans ton pgm qui plante ?

Le problème, c'est que je n'ai jamais trouvé le coupable...

Mais quand, par exemple, je me sers d'un de mes PC (Windev + thunderbird + FileZilla + Firefox + TeamViwer + antivirus Panda + qq autres ouverts) et que le système me dit que Windows ferme Explorer parce qu'il met le système en danger, je ne m'inquiète même plus et je ne me pose pas de question : je relance Explorer et tout rentre dans l'ordre !

Mais mon client trouve anormal de voir son application relancer disons en moyenne 2 fois par semaine.

Ce qui fait qu'avec mon petit programme de relance qui masque ces 'détails', tout va très bien.

Et comme je craque, j'arrête de me prendre la tête avec ça. Je dis - a tort ou a raison - qu'avec Windows et un PC, je ne ferai pas mieux...