PayPal Soap Anbindung

[TiGü]

Zitat von Dennis07:

Zitat von Harry29:

Delphi-Quellcode:

procedure TTest.PayPalTest;
var
  Soap: THTTPRIO;
  PayPal: PayPalAPIInterface;
  Sec: RequesterCredentials;
  Request:  RefundTransactionReq;
  Response: RefundTransactionResponse;
begin
  Soap := THTTPRIO.Create(nil);
  try
    //...
    Request := RefundTransactionReq.Create;
    Request.RefundTransactionRequest := RefundTransactionRequest.Create;
    Response := PayPal.RefundTransaction(Request);
  finally
    FreeAndNil(Response);
    FreeAndNil(Request);
    CoUnInitialize;
  end;
end;

Außerdem: Gewöhne dir an, alle Typen mit einem "T" und alle Interfaces mit einem "I" im Namen zu beginnen. Das macht es einfacher, sie zu identifizieren und von Standardtypen auseinander zu halten. Ich weiß jetzt nämlich zB nicht sicher, was bei dir ein Interface und was ein Klassen/Recordtypen hat. Das ließe sich leicht vermeiden. Ich sehe außerdem, dass du "Request.RefundTransactionRequest" erzeugst, aber nirgendwo freigibst. Ist es ein Interfaced-Typ mit Refcounting? Falls nein: Diesen MUSST du natürlich auch wieder freigeben, es reicht nicht, nur das Mutterobjekt freizugeben.

Hast du schon mal mit Delphi und SOAP bzw. mit Quelltext gearbeitet, der per Import einer WSDL-Datei in die Delphi-IDE zu einer Delphi-Unit umgewandelt wurde?
Eher nicht, oder?

Die Typen fallen so aus dem Quelltextgenerator raus. Klar kann man die umbenennen oder Aliase mit T dazuschreiben, aber wozu der Aufwand?
Die Freigabe von RefundTransactionRequest geschieht mit ziemlicher Sicherheit im Destroy von Request.

[Dennis07]

Zitat von TiGü:

Hast du schon mal mit Delphi und SOAP bzw. mit Quelltext gearbeitet, der per Import einer WSDL-Datei in die Delphi-IDE zu einer Delphi-Unit umgewandelt wurde?
Eher nicht, oder?

Nö. Hattest du geschrieben dass es ein automatisch generierter Source ist? Falls ja, hab ich es überlesen

Zitat von TiGü:

Die Freigabe von RefundTransactionRequest geschieht mit ziemlicher Sicherheit im Destroy von Request.

"mit ziemlicher Sicherheit"? Das ist ja schön. Kannst du mal nachschauen, was im Konstruktor von "RefundTransactionRequest", beim Destruktor von "RefundTransactionReq", und in "CoUnInitialize" genau passiert?
Und selbst, wenn das so ist, wäre das eine weitere Fehlerquelle: Falls die Instanz (aus welchem Grund auch immer) der Parent class oder vom Childobjekt nicht erzeugt wurde, kriegst du 100% eine Fehlermeldung, im ersten Fall sogar noch ein Memory-Leak, da du ja das Objekt bereits erzeugt hast, was nun aber nicht zugewiesen werden kann.

[TiGü]

Zitat von Dennis07:

Zitat von TiGü:

Hast du schon mal mit Delphi und SOAP bzw. mit Quelltext gearbeitet, der per Import einer WSDL-Datei in die Delphi-IDE zu einer Delphi-Unit umgewandelt wurde?
Eher nicht, oder?

Nö. Hattest du geschrieben dass es ein automatisch generierter Source ist? Falls ja, hab ich es überlesen

Zitat von TiGü:

Die Freigabe von RefundTransactionRequest geschieht mit ziemlicher Sicherheit im Destroy von Request.

"mit ziemlicher Sicherheit"? Das ist ja schön. Kannst du mal nachschauen, was im Konstruktor von "RefundTransactionRequest", beim Destruktor von "RefundTransactionReq", und in "CoUnInitialize" genau passiert?
Und selbst, wenn das so ist, wäre das eine weitere Fehlerquelle: Falls die Instanz (aus welchem Grund auch immer) der Parent class oder vom Childobjekt nicht erzeugt wurde, kriegst du 100% eine Fehlermeldung, im ersten Fall sogar noch ein Memory-Leak, da du ja das Objekt bereits erzeugt hast, was nun aber nicht zugewiesen werden kann.

Wenn du schon drei Jahre alte Threads ausgräbst - warum das Leute immer wieder machen entzieht sich meinem Verständnis - dann wäre es gut, wenn du
a) den ganzen Thread liest (man beachte hierbei die ersten drei Zeilen des Eröffnungsposts nach der Begrüßung von Harry29) und
b) Erfahrung mit den Dingen hast, über die gesprochen wird.

Es gilt die alte Regel: Wenn keine Erfahrung vorliegt -> nicht dazu posten!

[Dennis07]

Zitat von TiGü:

Wenn du schon drei Jahre alte Threads ausgräbst - warum das Leute immer wieder machen entzieht sich meinem Verständnis

https://www.facebook.com/groups/1370...8672088509186/ ...

Zitat von TiGü:

Es gilt die alte Regel: Wenn keine Erfahrung vorliegt -> nicht dazu posten!

Gut, dann tu das auch nicht! ...

Zitat von TiGü:

Kenne mich mit der Thematik auch null aus

Mal ganz abgesehen davon: Ich würde es begrüßen, wenn du mal einen angemessenen Ton anschlägst. Auf so ein Anmotzen hab ich hier offen gesagt keinen Bock.

[makulik]

Hallo Zusammen,

Wenn, Ihr mit Eurem merkwürdigen Hin- und Her-Geplänkel hinsichtlich des angemessenen Tons in technischen Foren fertig seid, dann können wir uns ja mal wieder mit dem eigentlichen Problem beschäftigen (wer Lesen kann ist übrigens immer klar im Vorteil).

Derjenige, der das 3 Jahre alte Thema wieder ausgegraben hatte und nach einer Lösung sucht bin ich. Ich hatte eine entsprechende Anfrage in der FB Delphi Developer Group gestellt:

Memory leak with Delphi 10 Seattle generated Soap from PayPal WSDL.

Leider kam da bislang nicht mehr rüber, als wilde Spekulationen, wie die Speicherverwaltung unter Delphi funktioniert.
Embarcadero scheint das Problem ja offenbar nicht zu interessieren, sonst hätte man wohl einen Fix, oder wenigstens Vorschläge für einen Workaround mit einer fundierten Recherche finden können.
Ich habe das exakt gleiche Problem (mit einer wesentlich aktuelleren Delphi Version), und Source Code der Memory-Leaks produziert pflege ich nicht in Produktion zu geben; soviel dazu und genug zum Vorwort.

--------------------------------------------------------

Also zunächst mal liegt das Problem nicht an dem RequesterCredentials Objekt, das für den SOAP Request erzeugt wurde (der Soap.SOAPHeaders.SetOwnsSentHeaders(True); Mechanismus funktioniert wie er soll), sondern das für den SOAP Response vom PayPal Server ebenfalls ein RequesterCredentials SOAP Header (mit leeren Feldern) zurückgesandt wird und vom Parser ein entsprechendes Objekt instanziiert wird.

Das kann man eigentlich auch schön in TiGü's FastMM Stack Trace sehen:

[Optosoapdomconv.TOPToSoapDomConvert.ProcessResponse$qqrxp22System.Classes.TStreamrx27Soap.Intfinfo.TIntfMetaDatarx28Soap.Intfinfo.TIntfMethEntryp31Soap.Invokeregistry.TInvContextp31Soap.Invokeregistry.THea ProcessResponse ist diesbezüglich ziemlich unmissverständlich.

Die SOAP Header werden nun leider nicht automatisch mit dem decodierten SOAP Body Object freigegeben, soweit ich den Source Code analysiert habe.

Die Response Header werden in einer generischen TObjectList<T> von TSOAPHeaders.FInHeaders (oder so) gespeichert, für die die OwnsObjects Eigenschaft auf true gesetzt ist, soweit ich das heute debugged habe.
D.h. im Klartext, dass die Response Header Objekte eigentlich spätestens beim Zerstören des TSOAPHeaders Objekts abgeräumt werden sollten(!) was aber aus irgendeinem obskuren Grund nicht passiert (TObjectList<T> funktioniert eigentlich ausnahmsweise einwandfrei, soweit mir bekannt ist). Daher das finale Memory-Leak.

Was mir beim Debuggen heute auch noch aufgefallen ist, ist dass das in der Liste gespeicherte TSOAPHeader Objekt von der RTTI nicht als RequesterCredentials Typ erkannt wird, sondern als dessen (generierte) Basis Klasse CustomSecurityHeaderType.

Der vom WSDL Component Generator erzeugte Code sieht so aus:

Delphi-Quellcode:

   RequesterCredentials = class(CustomSecurityHeaderType)
   private
   published
   end;

Ich habe versucht mittels

Delphi-Quellcode:

procedure MyProcedure();
var
    headerAccess : ISOAPHeaders;
    respCredentials : RequesterCredentials;
begin
    // ...

    respCredentials := headerAccess.Get(RequesterCredentials) as RequesterCredentials;

    // ...
    respCredentials.Free();
end;

das Header Objekt explizit zu holen und freizugeben, was allerdings scheitert, da das in der Liste gespeicherte Objekt tatsächlich vom Typ CustomSecurityHeaderType ist.

Weiter bin ich heute nicht mehr gekommen, aber ich glaube ich bin der Lösung (dem Workaround) schon ziemlich nahe.

Der ganze generierte Kram aus dem WSDL basiert übrigens als Super-Super Klasse auf TObject, und leider nicht auf TInterfacedObject und entsprechenden Reference Counted Interface Objekten (TRemotable ist leider nur ein TObject ohne Interface), was die ganze Angelegenheit (Speicherverwaltung) wohl erheblich vereinfachen würde.

Sobald ich in der Lage bin Weiteres zur Lösung des Problems beizutragen, werde ich dies hier tun (morgen hoffentlich).

Gruss,
Günther

P.S.:
Wenn irgendjemand weitere konstruktive und fundierte Beiträge zur Lösung des Problems beitragen möchte, ist dies ausdrücklich erwünscht!

[makulik]

Leider ist es so, dass tatsächlich Embarcadero den Fehler (das Memory-Leak) verursacht.

Das Problem ist der folgende Code in der Funktion TSOAPDomConv.ConvertSOAPToObject aus Soap.OPToSOAPDomConv.pas ab Zeile 4768:

Delphi-Quellcode:

function  TSOAPDomConv.ConvertSOAPToObject(RootNode, Node: IXMLNode; AClass: TClass;
  const URI, TypeName: InvString; ObjP: Pointer): TObject;

// ...
    if Assigned(Obj) and LegalRef then
    begin
     if (NodeClass <> nil) and (NodeClass <> Obj.ClassType) then
        Obj.Free(); // Dieses Free hat gefehlt, die alte Instanz von Obj dangled nach dem Überschreiben
        Obj := NodeClass.Create;
    end

// ...

Ist auch in der aktuellen Delphi Version (Tokyo) noch vorhanden. Vermutlich gibt es auch noch weitere Stellen die ein ähnliches Problem haben.
TObject ist nun mal nicht ref-counted
Ich werde ein Ticket bei Embarcadero aufmachen.

Gruss,
Günther

[mkinzler]

Dann sollte man die beiden Zeilen aber auch mit begin..end umschliessen.

[TiGü]

Zitat von makulik:

Leider ist es so, dass tatsächlich Embarcadero den Fehler (das Memory-Leak) verursacht.

Das Problem ist der folgende Code in der Funktion TSOAPDomConv.ConvertSOAPToObject aus Soap.OPToSOAPDomConv.pas ab Zeile 4768:

Delphi-Quellcode:

function  TSOAPDomConv.ConvertSOAPToObject(RootNode, Node: IXMLNode; AClass: TClass;
  const URI, TypeName: InvString; ObjP: Pointer): TObject;

// ...
    if Assigned(Obj) and LegalRef then
    begin
     if (NodeClass <> nil) and (NodeClass <> Obj.ClassType) then
        Obj.Free(); // Dieses Free hat gefehlt, die alte Instanz von Obj dangled nach dem Überschreiben
        Obj := NodeClass.Create;
    end

// ...

Ist auch in der aktuellen Delphi Version (Tokyo) noch vorhanden. Vermutlich gibt es auch noch weitere Stellen die ein ähnliches Problem haben.
TObject ist nun mal nicht ref-counted
Ich werde ein Ticket bei Embarcadero aufmachen.

Gruss,
Günther

Wenn man sich in der Methode den XML-Text vom RootNode anschaut sieht man folgendes:

Code:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cc="urn:ebay:apis:CoreComponentTypes" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:ed="urn:ebay:apis:EnhancedDataTypes" xmlns:ebl="urn:ebay:apis:eBLBaseComponents" xmlns:ns="urn:ebay:api:PayPalAPI">
   <SOAP-ENV:Header>
      <Security xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext" xsi:type="wsse:SecurityType"/>
      <RequesterCredentials xmlns="urn:ebay:api:PayPalAPI" xsi:type="ebl:CustomSecurityHeaderType">    <<<--------- Hier ist der Übertäter
         <Credentials xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:UserIdPasswordType"/>
      </RequesterCredentials>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body id="_0">
      <RefundTransactionResponse xmlns="urn:ebay:api:PayPalAPI">
         <Timestamp xmlns="urn:ebay:apis:eBLBaseComponents">2018-06-14T11:41:34Z</Timestamp>
         <Ack xmlns="urn:ebay:apis:eBLBaseComponents">Failure</Ack>
         <CorrelationID xmlns="urn:ebay:apis:eBLBaseComponents">ac2341fd2df09</CorrelationID>
         <Errors xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:ErrorType">
            <ShortMessage xsi:type="xs:string">Authentication/Authorization Failed</ShortMessage>
            <LongMessage xsi:type="xs:string">You do not have permissions to make this API call</LongMessage>
            <ErrorCode xsi:type="xs:token">10002</ErrorCode>
            <SeverityCode xmlns="urn:ebay:apis:eBLBaseComponents">Error</SeverityCode>
         </Errors>
         <Version xmlns="urn:ebay:apis:eBLBaseComponents">0.000000</Version>
         <Build xmlns="urn:ebay:apis:eBLBaseComponents">000000</Build>
         <RefundTransactionID/>
      </RefundTransactionResponse>
   </SOAP-ENV:Body></SOAP-ENV:Envelope>

Aufgrund von

Code:

xsi:type="ebl:CustomSecurityHeaderType"

wird ja in den Zeilen

Delphi-Quellcode:

  GetElementType(ObjNode, NodeURI, NodeTypeName);
  NodeClass := RemTypeRegistry.URIToClass(NodeURI, NodeTypeName, IsScalar);

die NodeClass auf CustomSecurityHeaderType gesetzt. Mit den bekannten Folgen.

Also Workaround - welche negativen Auswirkungen das hat, muss gesondert untersucht werden - kannst du in der PayPalSvc-Unit ca. bei Zeile 28049 das folgende auskommentieren:

Delphi-Quellcode:

...
RemClassRegistry.RegisterXSClass(CustomSecurityHeaderType, 'urn:ebay:apis:eBLBaseComponents', 'CustomSecurityHeaderType');
...

Dadurch wird RemTypeRegistry.URIToClass nichts finden und NodeClass wird zu nil.
Damit bleibt das Obj (=> RequesterCredentials) erhalten und das Speicherleck ist weg.