So, jetzt die Auflösung. Ich bin leider erst heute Nachmittag wieder dazu gekommen, das Problem abschliessend zu klären.
Meine These war schon richtig - ein $Ref-Value führte die rekursive Routine zur Verzweiflung. Meine Ahnung war, dass ein Response Document wieder auf das Hauptdokument verweist oder eine Response zur Response auf die erstere. Mein Respekt gilt Thomas Schulte, mit dem ich gestern in anderer Sache telefonierte und mit ihm auch diesen Fall diskutierte: Seine Idee, dass das Response Document auf genau sich selbst verwies, entsprach genau den Tatsachen.
Meine Routine prüft nun einerseits eben diesen Fall ab (UNID = $Ref) als auch (konfigurierbar) die erlaubte Tiefe des rekursiven Aufrufs (das ist ja alles kein Hexenwerk, und ich hätte zumindest letzteres schon längst in entsprechenden Verfahren eingebaut haben müssen).
Nun habe ich damit zwei neue Probleme:
1. Alle rekursiven Verfahren nachträglich entsprechend absichern, weil: Passieren kann sowas ja immer.
2. Ich muss die Ursache finden, wie dieser Fall überhaupt entstehen konnte. Die Anwendung, in der dieses "unmögliche" Antwortdokument entstanden ist, ist zu 100% von mir, und in die Entstehung von Antwortdokumenten
dieser Art kann kein User eingreifen. Ein Dokument aus 55.000 ist in meinem Verständnis genau eines zu viel.
Bernhard
PS: Die Fehlermeldungen, die ein R5 oder R 8 (Standard bzw. Basic) liefert, mag ich nicht nachreichen - die Applikation ist schon umgebaut, und deswegen retour mag ich jetzt nicht
Getestet hatte ich aber heute nochmal mit einem 6er (als versaubare Testumgebung). Mein ErrorHandler meldete vorab noch brav den stack overflow, und die Meldung des Clients empfand ich dann eigentlich sauberer als die des 7er (warum sollte ich mich mit dem Compiler beschäftigen, die der Hersteller meiner Middleware verwendet?)
