Discussion :

[JeanRad]

Bonjour,

Nous avons une application conçu sur la base de XMLRAD. Nous constatons une consommation de mémoire récurrente qui nous oblige à relancer l'application toutes les deux heures.

Après investigation et revue de code, nous nous sommes aperçus que la consommation de mémoire aller de paire avec le nombre de XMLCursor et la taille du « Limbo » qui grandi. En allant plus loin, nous avons identifié que ce sont principalement des XMLCursor de type « OutputDoc » créés par la fonction TXMLService.CreateDocument qui sont conservés (en dizaine de milliers), voir la trace ci-après.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
01/09/2009 09:39:29 [$11475F20]<289882160>(0000000009) - Age(140,2070325279) - OutputDoc
             0 : [$02780AD8] ..\..\..\XMLCLX\Source\XMLService.pas XMLService.CreateOutput(939)
             1 : [$02781813] ..\..\..\XMLCLX\Source\XMLService.pas XMLService.TXMLService.CreateDocument(1092)
             2 : [$02782126] ..\..\..\XMLCLX\Source\XMLService.pas XMLService.TXMLService.CreateContent(1275)
             3 : [$02784C22] ..\..\..\XMLCLX\Source\XMLService.pas XMLService.TXMLService.Execute(1887)
             4 : [$027776E1] ..\..\..\XMLCLX\Source\XMLComponent.pas XMLComponent.TCustomXMLComponent.Execute(555)
             5 : [$0274A018] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.ExecuteActionComponent(1475)
             6 : [$0276B490] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.TXMLApplication.XMLCollectionDispatchRequest(9125)
             7 : [$02755BAC] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.TXMLApplication.GetAvailableXMLCollectionAndDispatchRequest(4416)
             8 : [$0275A3D2] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.InternalGlobalDispatchRequest(5353)
             9 : [$0275AA8D] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.TXMLApplication.InternalDispatchRequest(5416)
            10 : [$02747DF7] ..\..\..\XMLCLX\Source\XMLApp.pas XMLApp.TXMLDispatchThread.Execute(873)
            11 : [$025CBB0F] common\Classes.pas Classes.ThreadProc(9877)
            12 : [$025A5512] C:\builds\Tp\rtl\sys\system.pas System.ThreadWrapper(12108)

Une personne sait-elle dans quelle structure sont conservés ces XMLCursor ?
Nous voudrions pouvoir les libérer pour nous éviter de devoir relancer notre application et voir aussi nos performances décroitre.

Cordialement.

[Georges_Lauret]

OutputDoc s'élimine tout seul à la fin de la requête... A moins que vous ayez encapsulé des sections dans des XML_Cache ?
Pour répondre il faudrait avoir le xmlService

[JeanRad]

Merci de votre réponse, mais depuis ce matin, nous avons trouvé d'où venait le souci. C'est une anomalie XMLRAD qui existe depuis longtemps.

Le problème se situe dans la mathode TXMLGram.Process(const AInputDoc, AOutputDoc: IXMLCursor);. La correction consiste à effacer les deux XMLCursor InputDoc et OutputDoc suite à la ligne 3973. Notre outil de trace nous montre que la rétention des XMLCursor de type « OutputDoc » n'existe plus.

Code :

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

1
2
3
4
5
        finally
          CommitTransactions(XMLRequest);
	  InputDoc := nil;
	  OutPutDoc := nil;
        end;

Cordialement.

[Georges_Lauret]

S'il vous plait : quelle version XMLRAD utilisez-vous ?
Je ne trouve pas les lignes citées dans mon source ...

Georges

[JeanRad]

Attention dans le code suivant :

Code :

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

1
2
3
4
5
        finally
          CommitTransactions(XMLRequest);
	  InputDoc := nil;
	  OutPutDoc := nil;
        end;

Les lignes concernant InputDoc et OutputDoc sont rajoutées. Donc pour vous, ce qui est important c'est de prendre en compte la méthode TXMLGram.Process(const AInputDoc, AOutputDoc: IXMLCursor); de l'unité XMLGram.pas, puis le numéro de ligne 3973 qui doit désigner le CommitTransactions dans un finally ou rechercher cette séquence dans cette méthode. La version que nous utilisons est une 2007.

[Jeweller]

Bonjour,
Tu pointes sur quelque chose d'interessant effectivement, mais je pense qu'il y a autre chose derriere.... ces curseurs devraient être "libéré" lors de la destruction du TXMLGRAM. Je n'ai pas creusé mais tu as l'air de dire que ce n'est pas le cas, mais c'est possible. Peut etre alors faudrait-il se pencher aussi sur ce problème... Ou alors tu garderais qqs part dans tes traitements une référence à un objet xmlgram qui ne serait jamais libérée ?

Ceci dit, ta modif parait cohérente vu que InputDoc et OutputDoc sont initialisés plus haut (on peut supposer qu'on en a plus besoin apres).

Michael

[JeanRad]

Bonjour,

En fait au sein d'une application pas très complexe, avec peu d'écran, cela se conçoit de garder ces XMLCursor de type OutputDoc pour que MSXML garde ses affectations mémoires, suivant les propos de Delos. Avec les premières versions de MSXML, cette rétention s'avérait utile. Aujourd'hui, très rapidement, en fonction des usage de l'application, MSXML 6 SP2 sait réserver de la mémoire pour faire appel au gestionnaire de mémoire, le moins possible.
Dans notre cas, au bout de deux heures nous étions obligés de recycler l'application.
Deuxièmement, ces XMLCursor conservés ne sont intéressants que pour les données statiques, la partie dynamique correspondant aux informations issues de la base de données est quant à elle libérée et rechargée. Ceci minimise l'intérêt de la rétention.

Ta réflexion à propos des XMLGram me dit que je vais aussi jeter un coup d'oeil de ce coté là et voir leur utilité dans le temps.

Cordialement.

[ploup]

Bonjour,

Ou se trouve le fichier XMLGram.pas dans la DLL XMLCLX ?

En effet je rencontre le même problème mais je n'ai pas accès au sources de la DLL ? Que devons-nous faire ? Décompiler la DLL ?

Par ailleurs avez-vous trouver une autre solution que de corriger le fichier XMLGram.pas ?

Merci

[Georges_Lauret]

http://dev.geo-run.com/Ressources-xmlrad/

[ploup]

Merci pour la documentation.

Mais comment je peux récupérer les sources la DLL ? Est-il possible de la décompiler ?

Si oui comment pouvons ensuite la recompiler ?

Merci de votre aide.