Discussion :

[DSKLU]

Bonjour,

j'ai une application client/serveur qui tourne avec firebird sur un serveur windows 2003 server avec 2 interfaces reseaux, à certaines plages de la journée (vers 17h et 19h), le service FirebirdServerDefaultInstance plante et fait planter tous les utilisateurs de l'application, le service redémarre automatiquement car le service guardian est installé mais j'ai un message dans l'observateur d'événement qui stipule :

"The description for Event ID ( 281 ) in Source ( FirebirdGuardianDefaultInstance ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Abnormal Termination: C:\Program Files\FireBird\bin\fbserver.exe: terminated abnormally (4294967295)."

sur les forums, on me signale que c'est un probleme reseau mais l'administrateur réseau teste tout depuis trois semaines sans succés.

on a beaucoup d'erreur 10054 dans les logs firebird mais qui ne font pas planté l'application.

on note dans les logs du logiciel que à ce moment (ou presque) un utilisateur s'est déconnecté du logiciel

on a un service d'une autre application (ne faisant rien de particulier à ce moment) utilisant firebird qui a mis une dependance au service firebird.

1°) comment obtenir un message d'erreur explicite, quelle dll installée (on a essayé sans succés fbscanner trial version) et le monitor de delphi mais comme le problème vient de manière aléatoire, on ne peut le cerner.

2°) que peut-on verifier de bloquant à la fin du soft pour eviter un plantage firebird ?

3°) est-ce que quelqu'un à déjà eue ce type de probleme ?

merci pour vos réponses

[Barbibulle]

Bonjour,

L'erreur 10054 est en effet une erreur liée à des problèmes de votre réseau et ne doit pas faire crasher le serveur.

Quel est la charge du serveur ? Nombre de connexion au moment du crash. Est ce un pic de charge ou non ?

Avez vous essayé ne ne pas lancer la service de l'autre application qui est dépendant du service firebird voir si ça plante toujours.

[makowski]

essayez de faire travailler Firebird sur une seule des cartes réseau dans firebird.conf RemoteBindAddress

[DSKLU]

Bonjour,

merci pour les réponses,

Quel est la charge du serveur ? ce serveur est neuf et est dédié à nos applications et est en sous charge tout le temps (4GO de memoire disponible, 20 à 30 % utilisé)


Nombre de connexion au moment du crash. Est ce un pic de charge ou non ? une trentaine de connexion est détectée dans l'apres-midi et au moment du crash (vers 19h), il doit en rester une quinzaine

Utiliser une seule interface réseau : les applications sont en production depuis 2 réseaux distincts, il est impossible meme pour un temps tres court de couper un des deux reseaux car l'application sert à prendre des rendez vous en direct suivant une charge de travail. Sur notre serveur local, nous n'avons qu'une interface reseau et nous voyons dans les logs des erreurs du meme type malheureusement indéfini (bcp moins frequente car nous ne l'utilisons pas bcp comparé à la production)

Lorsque j'utilise l'application directement sur le serveur, j'obtiens parfois un message de hanging application dans le event viewers lorsque l'application plante ? savez-vous ce que cela signifie ?

Vendredi et samedi, je n'ai eu qu'un plantage par jour au lieu de deux, nous avons arrêter un service dont dépendait le service firebird, nous avons arrêté l'antivirus et les maj et nous avons mieux libéré la mémoire dans l'application principale.
Nous restons toujours disposer à tester vos solutions dans la mesure du possible.

[makowski]

vous avez des udf maison ?

[Cl@udius]

Restauration des messages du 23 au 28

Oui, nous avons des UDF. C'est une piste que nous suivons car dans un des logs (fbscanner au moment d'un plantage)nous avons eu un message de probleme de cast :
"16/07/2008 18:58:12
Exception: System.InvalidCastException: Unable to cast object of type 'FBScannerPublic.YaClientData' to type 'FBScannerPublic.YaClientData_Con' "

Cela vous donne une piste ?

à part dire que votre udf est certainement mal écrite ...

c'est un grand classique, les erreurs que vous rencontrez quand des udf sont mal écrites, surtout avec FB < 2.x

peut être des fuites mémoires

DECLARE EXTERNAL FUNCTION MINUTEHC
INTEGER,CSTRING(1),INTEGER
RETURNS CSTRING(8)
ENTRY_POINT 'MinuteHC'
MODULE_NAME 'DSKUDF.dll'

et voici un bout de code de la procedure stockee qui pourrait poser probleme :

"cast(cast(RDVDateFrom as date) as char(10)) as rdvdatefrom"

on veut recupéré la date en timestamp sur 10 caracteres

merci de me dire si vous voyez un probleme à ce code.

DSKUDF pour "Dominique Strauss-Kahn Union pour la Démocratie Francaise" ?



Ce qui souvant bug dans les UDF maison sont les types chaine de caractères. Soit elles sont mal allouées mais surtout mal libérée.
Ou bien l'utilisation de variables 'globales'....

A vous de voir dans le code de votre DSKUDF.dll que vous avez développé si c'est le cas ou non.

Apres le code de votre PS :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cast(cast(RDVDateFrom as date) as char(10)) as rdvdatefrom

RDVDateFrom est de quel type (vous ne donnez pas la déclaration).

Je suppose que c'est un type timestamp. Et je ne vois pas ce qui peut lui poser probleme.
Le 1er cast as date tronc la partie time et le 2eme le met sous forme de chaine 'AAAA-MM-JJ'.

le service FirebirdServerDefaultInstance plante et fait planter tous les utilisateurs de l'application,

Je réagis par rapport à ça.

J'en conclus que vous avez installé firebird superserveur (Qui est l'installation la plus rependue sous windows je pense.)

Ma question est un peu hors sujet mais vous intéressera peut être. Pourquoi ne pas installer firebird classic-serveur ?

Sauf erreur de ma part (je pense que makowski confirmera) dans ce mode là les clients sont autonomes et s'il y en a un qui fait planter firebird cela ne fait pas planter les autres. La contre partie c'est peut être une baisse de performance et encore que si votre serveur est multi processeurs ou multi cores le classic est plus adapté.

Normalement une application qui fonctionne en superserveur marche en classicserveur sans modification (j'ai jamais testé, et là ou j'ai un doute c'est avec fb1.5 si on cherche a savoir qui est connecté en classic il me semble qu on ne vois que sa propre connexion). Et je me demande aussi s'il n'y a pas une contrainte supplémentaire pour les UDF.

Si makowski pouvais m'éclairer.

pas de contraintes supplémentaire
utiliser Superserveur ou classique ne change rien pour une application

la vraie question est : que fait cette udf, à quoi sert elle ?
et donc comment éventuellement changer son code ou mieux, s'en passer

pas de contraintes supplémentaire
utiliser Superserveur ou classique ne change rien pour une application

Oui ça j'avais bien compris mais en mode classic serveur le plantage d'un client ne fait pas planter les autres il me semble.

oui, ça forcément, par définition, puisque classic, c'est un processus par connexion

[DSKLU]

Bonjour,

pour répondre à votre question, nous avons fait une version sans UDF.
Malheureusement, cela plante toujours.
Nous cherchons toujours.

Merci de votre aide.

[ddaime]

Essayez de mettre à jour Firebird en version 2.1 dans un premier temps, au cas où.

[makowski]

Bonjour,

pour répondre à votre question, nous avons fait une version sans UDF.
Malheureusement, cela plante toujours.
Nous cherchons toujours.

alors il faudrait beaucoup plus de détails et d'expertise
sans connaitre le contexte exact, les log complet, tout ce qui utilise Firebird, comment, c'est difficile à dire
mais c'est vrai que changer de version pour passer à une 2.1.1 ou 2.0.4 peu aider, la gestion des ressources étant bien meilleure que dans 1.5

[DSKLU]

Malheureusement, tous les programmes de la société tourne avec 1.5 et migré tout n'est pas envisageable pour l'instant !

[DSKLU]

Bonjour,

nous avons résolu le problème par une modification de l'appel des dll et de la fermeture de l'ensemble du logiciel, les 2 cartes réseaux sur le serveur étaient bien un facteur aggravant.

Merci pour votre aide.

[ddaime]

nous avons résolu le problème par une modification de l'appel des dll et de la fermeture de l'ensemble du logiciel, les 2 cartes réseaux sur le serveur étaient bien un facteur aggravant.

Qu'entendez vous par "modification de l'appel des dll", c'est Firebird qui gére en interne l'appel des DLL pour accéder aux fonctions, de plus il n' a pas trente six façon de déclarer une DLL dans Firebird. Qu'avez vous modifiez alors ? Et en effet, c'est rassurant de voir que Firebird ne plante plus aprés avoir fermer l'ensemble de vos logiciels utilisant Firebird, ca prouve le probléme est du coté "client". J'ai pas tout compris pour les 2 cartes réseaux, pourquoi c'était un facteur aggravant ?