Laden...

Große Antworten bei REST-Request verursachen Fehler

Erstellt von nevermind10844 vor 9 Jahren Letzter Beitrag vor 9 Jahren 1.413 Views
N
nevermind10844 Themenstarter:in
40 Beiträge seit 2011
vor 9 Jahren
Große Antworten bei REST-Request verursachen Fehler

Hallo Gemeinde.

Ich habe einen REST-Service im IIS7.5 gehostet und schicke einen Request an selbigen.
Dieser löst eine SQL-Anfrage an eine Datenbank aus (Anhand einiger Parameter im Request)
Wenn die Parameter eine recht geringe Zahl an Datensätzen hervorbringen, dann bekomme ich mittels SOAP UI eine korrekte Antwort im folgenden Stil zurück:

<ContactResponse xmlns="http://schemas.datacontract.org/2004/07/Service" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
   <Error i:nil="true"/>
   <Count>9</Count>
   <Contacts>
      <Contact>
         <CustomFields>
            <CustomField>
               <Key>EMAIL_DIREKT</Key>
               <Value/>
            </CustomField>
            <CustomField>
               <Key>EMAIL_PRIVAT</Key>
               <Value/>
            </CustomField>
            <CustomField>
               <Key>EMAIL_ZENTRALE</Key>
               <Value>info@jk.de</Value>
            </CustomField>
            <CustomField>
               <Key>FAX_DIREKT</Key>
               <Value/>
            </CustomField>
            <CustomField>
               <Key>FAX_PRIVAT</Key>
...

Wird die Zahl der zurückgegebenen Datensätze zu groß, dann bekomme ich leider keine Korrekte Antwort mehr.

Ich kann sehen, dass die Daten vom SQL-Server auch im Fehlerfall korrekt abgerufen werden.
(Dies geschieht über eine eigenständige Komponente, die als Konsolenanwendung läuft und vom Service abgefragt wird. Diese Zeigt mir sämtliche anfragen und antworten, die rein und rausgehen, sowie die Zeilenzahl des Ergebnisses der Datenbankabfrage.)

Bei einer bestimmten Zahl von Datensätzen (momentan 9), zeigt sich folgendes Verhalten:
Mal bekomme ich ein korrektes Ergebnis, mal nicht. Die Chance dürfte ungefähr 50% betragen.

Das hat mich auf den Gedanken gebracht, dass die Datenmenge und die Datenlänge nicht das
relevante Kriterium ist, sondern die Zeit.

Googlen hat diverse Ergebnisse geliefert:
(Versuch macht Klug... oder auch nicht!)

<webHttpBinding>
        <binding name="RESTConfig" receiveTimeout="00:10:00" sendTimeout="00:10:00" openTimeout="00:10:00" closeTimeout="00:10:00" >
          <security mode="None"/>
          <readerQuotas maxArrayLength="2147483647" maxStringContentLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/>
        </binding>
      </webHttpBinding>

Hat leider nichts gebracht.

Eine Erfolgreiche Anfrage mit 9 Datensätzen hat folgende Eckdaten:
132 ms, 19273bytes (laut SOAP UI)

Hat jemand eine Idee wodurch das Problem zustandekommt?
Ich finde einfach nichts weiteres!

Beste Grüße!

Nachtrag: Ich habe mal die Ablaufverfolgung deaktiviert mit der Vermutung, dass diese einige Zeit in Anspruch nimmt! Nun liegt dieser strittige Punkt bei 19 Datensätzen mit 40040bytes und 213 ms.

849 Beiträge seit 2006
vor 9 Jahren

Hallo, was bekommst Du stattdessen zurück? Schonmal mit dem Fiddler die Requests angeschaut?

16.835 Beiträge seit 2008
vor 9 Jahren

Benutzt Du jetz REST oder SOAP?

N
nevermind10844 Themenstarter:in
40 Beiträge seit 2011
vor 9 Jahren

Hi, ich benutze REST, schicke aber Anfragen mit Soap UI (kann halt auch Rest) an den Service!

Die Antworten gaben mir eine NullPointer zu verstehen.
Leider war nirgends eine Zeile oder eine Objekt zu lesen, auf die/das sich diese beziehen könnte.

Ich konnte jetzt jedoch das Problem an einer Stelle ausmachen, die für die Kommunikation des Services mit der darüberliegenden DAL verantwortlich ist. Dort wurde (warum auch immer) aus dem Stream gelesen, bevor in selbigen hineingeschrieben wurde. Somit hat die Kommunikation geendet, bevor die gesamten Daten übertragen wurden und das Objekt konnte nicht deserialisiert werden. Daraus folgte der Fehler bei der Antwort des Rest-Service.

Ich habe nun als Workaround ein Thread.Sleep verbaut und schaue demnächst nach einer eleganteren Methode.

Grüße und Dank!

849 Beiträge seit 2006
vor 9 Jahren

Die Antworten gaben mir eine NullPointer zu verstehen.

Das wäre (inkl stacktrace) eine Wichtige Information gewesen.. Nur für die Zukunft. Denn das hätte die Anzahl der möglichen Fehlerquellen drastisch reduziert.