Dll Pluggin - Service Unavailable [Résolu]

[Jeweller]

Bonjour,
Sur un serveur de tests qui héberge déjà plusieurs app XMLRAD (qui fonctionne bien!), je tente d'en déployer une autre (mode pluggin XMLRAD2005, 2 fichiers dll, Win2003). Je l'ai placé dans un pool distinct. Si je l'invoque en faisant /PING elle répond bien, par contre rien d'autre ne fonctionne (IE affiche une page d'erreur réseau: "la page est indisponible, le site web que vous recherchez rencontre peut etre des difficultés, blablabla"). Dans le journal Windows je peux lire:

Un processus servant le pool d'application 'WebServices' s'est arrêté de façon inattendue. L'identificateur de processus était '816'. Le code de sortie du processus était '0xeedfade'.

Apres 5 invoquations provoquant tjrs cette même erreur, le pool s'arrète et j'ai 'Service Unavailable' (logique).
Je n'ai aucune log ni aucune trace de l'application XMLRAD (même les fichiers ne sont pas créés, pourtant les droits sont bons).
Je ne comprends pas d'ou ca vient, sur mon poste de développement , l'appli fonctionne tres bien. Elle est d'ailleurs tres light (1 xmlmodule par dll et qqs xmlservices).
Chose interessante, si je retire la seconde dll, ca fonctionne normalement!
Avez vous une piste à m'indiquer trouver la cause du pb? Pourquoi le chargement de la dll pluggin echoue dans ce cas ?

Michael

[RDM]

ca sent effeictvement le crash au chargement du plugin
tu peut mettre les traces en verbose complet sur tous les groupes et en décoché le mode Async pour essayer de chopper quelques traces...

[Jeweller]

Le mode verbose est en place (j'ai déjà activé toutes les traces possibles), mais aucun message. Par contre "en décocher le mode Async" je trouve ca ou ? (j'ai pas XMLRAD installé sur le poste, je modifie directement les fichiers xml). Je ne connais pas cette option.

Michael

[RDM]

tout en haut du fichier tu dois avoir <Async>1</Async>
faut le mettre à 0. s'il n'y ait pas faut le mettre

au passage les fichiers de conf sont décrits ici:

http://xmlrad.com/DelosBin/Delos.dll...5#EventLog.xml

[Jeweller]

Oui, effectivement. J'ai un peu de Trace maintenant, mais cela ne m'en apprend pas bcp plus!

09:46:31 945.187 0 - 0 TXMLApplication 2 InitFromConfigFile - Devices file not found: D:\IIS\WebServices\MOSIWs\Bin\Devices.xml
09:46:31 948.239 0 - 0 TXMLApplication 4 DLLName: MOSIWs.dll
09:46:32 242.214 0 - 0 TXMLApplication 2 InitFromConfigFile - Devices file not found: D:\IIS\WebServices\MOSIWs\Bin\Devices.xml
09:46:32 245.088 0 - 0 TXMLApplication 4 DLLName: MOSIWs.dll

et

09:46:31 933.035 0 - 0 TXMLApplication 3 ----------------------
09:46:31 933.280 0 - 0 TXMLApplication 3 XMLUtils initialized
09:46:31 933.707 0 - 0 TXMLApplication 3 XMLApplication created
09:46:31 933.915 0 - 0 TXMLApplication 3 XMLCGenerator created
09:46:31 934.088 0 - 0 TXMLApplication 4 begin XMLApplication.InternalDispatchRequest
09:46:31 934.303 1 - 0 TXMLApplication 4 begin InternalDispatchRequest.InternalGlobalDispatchRequest
09:46:31 934.494 1 - 0 XMLC_Stack 4 TXMLApplication.DispatchRequest.InternalGlobalDispatchRequest
09:46:31 934.679 1 - 0 XMLC_Stack 4 TXMLApplication.Initialize
09:46:31 934.873 1 - 0 TXMLApplication 4 begin TXMLApplication.Initialize
09:46:31 935.055 1 - 0 TXMLApplication 3 XMLApplication.Initialize
09:46:31 935.236 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - AppPath: D:\IIS\WebServices\MOSIWs\Bin\
09:46:31 935.408 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - AppFileName: D:\IIS\WebServices\MOSIWs\Bin\vclXML70.bpl
09:46:31 936.189 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - ConfigFile Loaded: D:\IIS\WebServices\MOSIWs\Bin\Config.xml
09:46:31 944.561 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - DefaultDataDir: D:\IIS\WebServices\MOSIWs\Data
09:46:32 230.033 0 - 0 TXMLApplication 3 ----------------------
09:46:32 230.251 0 - 0 TXMLApplication 3 XMLUtils initialized
09:46:32 230.678 0 - 0 TXMLApplication 3 XMLApplication created
09:46:32 230.884 0 - 0 TXMLApplication 3 XMLCGenerator created
09:46:32 231.057 0 - 0 TXMLApplication 4 begin XMLApplication.InternalDispatchRequest
09:46:32 231.273 1 - 0 TXMLApplication 4 begin InternalDispatchRequest.InternalGlobalDispatchRequest
09:46:32 231.463 1 - 0 XMLC_Stack 4 TXMLApplication.DispatchRequest.InternalGlobalDispatchRequest
09:46:32 231.714 1 - 0 XMLC_Stack 4 TXMLApplication.Initialize
09:46:32 231.910 1 - 0 TXMLApplication 4 begin TXMLApplication.Initialize
09:46:32 232.093 1 - 0 TXMLApplication 3 XMLApplication.Initialize
09:46:32 232.272 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - AppPath: D:\IIS\WebServices\MOSIWs\Bin\
09:46:32 232.452 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - AppFileName: D:\IIS\WebServices\MOSIWs\Bin\vclXML70.bpl
09:46:32 233.214 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - ConfigFile Loaded: D:\IIS\WebServices\MOSIWs\Bin\Config.xml
09:46:32 241.589 0 - 0 TXMLApplication 4 TXMLApplication.InitFromConfigFile - DefaultDataDir: D:\IIS\WebServices\MOSIWs\Data

Mais pas de trace d'une erreur quelconque... J'ai le sentiment que ma seconde dll n'est pas bonne du tout... mais ce qui me dépasse c'est que sur mon poste de dev ca fonctionne normalement! Il y a peut etre dépendence avec une bibliothèque qui n'existe pas sur le serveur de test, mais je ne vois pas quoi!
Ce qui est bizzard aussi c'est que ces log sont le résultat d'une seule requete... pourtant on dirait qu'il y a 2 initialization (les 2 dll peut etre) ??


L'erreur dans l'observateur d'évenement Windows reste inlassablement la même (même code de sortie systématiquement):

Un processus servant le pool d'application 'WebServices' s'est arrêté de façon inattendue. L'identificateur de processus était '1836'. Le code de sortie du processus était '0xeedfade'.

[RDM]

ce que je vois c'est qu'il y a un plantage juste après la trace:

Code :

09:46:31 948.239 0 - 0 TXMLApplication 4 DLLName: MOSIWs.dll

c'est juste au moment du LoadLibrary du plugin.
(tu peux rajouter des traces dans le framework pour affiner cela...)
donc effectivement la DLL ne doit pas être correcte.

le deuxième démarrage est la conséquence du plantage.

sur ton poste de dev tu es en 2003 avec pool aussi ?

[Jeweller]

Non, je mon poste de dev est en 2000 et celui de test en 2003. Ca peut etre une cause ?
J'ai reconstruit la seconde dll en vérifiant bien les dépendances pour etre sur, mais rien à faire... je vais essayer comme tu dis d'affiner la trace...
J'imagine que le code de retour ne te dit rien?

Michael

[RDM]

ah bin vi c'est une différence !
et effectivement le code retour me dit rien

[Jeweller]

On dirait vraiment que ca vient du loadLibrary... mais je suis top dans le flou!
Je ne vois déjà pas les différences qui peuvent exister entre une dll et l'autre, et je comprends encore moins pkoi indépendement elles fonctionnent, mais pas ensemble!!!!!! (si je supprime soit l'une, soit l'autre du dossier Bin, elles s'executent)

[Jeweller]

Aie Aie Aie.... J'ai installé les dll en question sur un 3ieme serveur bien différent sous win2003 (des appli xmlrad y fonctionnent déjà aussi tres bien) et je retrouve exactement les mêmes symptomes, même erreur, même code de sortie... Alors que ca marche sous mon windows2000. Je pige pas...

[Jeweller]

Desole, je vous distille un peu les infos comme elles me viennent dans l'espoir un peu fou que qqs me dise "tu as pensé à décocher la case, empecher le pluggin de fonctionner, ?" et que je me retrouve tout bete mais que ca fonctionne ensuite!
Alors voila, si je compile une des dll sans le mode "paquet d'execution" (pas le mode pluggin en gros) eh ben ca fonctionne (enfin ca en a l'air)!

?

[RDM]

est-ce qu'une application plugin de base (donc avec 2 dlls) fonctionnent sur un serveur 2003 ?
si oui il ne te reste plus qu' afire de la dichotomie entre les 2 jusqu'a savoir ce qui fait que ca plante...

[Jeweller]

Bon, j'ai fini par mettre le doigt dessus!
Dans une des unités qqs part dans un uses de uses de uses (une unité à la con partagé par deux ou trois truc qui défini qqs constantes), il y a tout en bas du fichier la ligne suivante:

Code :

GLock := TseMutex.Create('MTX_MOSNBRCOUNT');

Cette unité etait implicitement importée par les deux dll.. donc forcément, elle ne peuvent pas se charger en même temps en mémoire!!
Mais du coup je ne comprends pas pourquoi ca marchait sur mon win2000! Ca n'aurait jms du fonctionner!
Vive le travail coopératif ;-)

Michael

[RDM]

elle est pas mal celle là