Disconnect nach Backup DTAQ

[ParkerLouis]

Hallo zusammen,

ich bin neu hier im Forum und gespannt auf die Rückmeldungen!

Wir haben eine Anwendung gebaut, die auf einem Windows Client ständig eine DataQueue auf der AS/400 abfragt und verarbeitet.

Alles läuft sehr gut, bis auf die Tatsache, dass wenn die Datensicherung läuft wir im DataQueu.Read hängenbleiben.

Auch ein erneutes SignOn bringt nichts.

Wie kann man denn im Programm feststellen, ob man noch angemeldet ist?

[BenderD]

Hallo,

prüfen kann man das mit einem write/read ohne Wartezeit
am Besten baut man da einen Connection Pool drumherum, der sich um die Gesundheit der Connections kümmert, wenn man das Glück des Tüchtigen hat und Java verwendet, dann gibt es sowas weitgehend fertig. Der sorgt dann zusätzlich dafür, dass Verbindungen nur eine maximale Zeit und für eine maximale Anzahl von Anforderungen verwendet werden.
Alternativ könnte man auch vor der Sicherung die Anwendung kontrolliert (per shutdown Message in die Q) beenden und nach der Sicherung (per rexec o.ä.) wieder starten.

mfg

Dieter Bender

Hallo zusammen,

ich bin neu hier im Forum und gespannt auf die Rückmeldungen!

Wir haben eine Anwendung gebaut, die auf einem Windows Client ständig eine DataQueue auf der AS/400 abfragt und verarbeitet.

Alles läuft sehr gut, bis auf die Tatsache, dass wenn die Datensicherung läuft wir im DataQueu.Read hängenbleiben.

Auch ein erneutes SignOn bringt nichts.

Wie kann man denn im Programm feststellen, ob man noch angemeldet ist?

[ParkerLouis]

Hallo Herr Bender,

vielen Dank für die Infos.

Wir sind zwar nicht an .net gebunden, aber die ganze Applikation umzuschreiben ist dann doch zu viel Aufwand.

Ich habe hier im Java Forum auch gelesen, dass es Probleme gibt mit dem Timeout beim Read einer DataQueue. Wenn mein DataQueue Objekt auf Daten wartet und dann auf dem System ein Backup durchgeführt wird, dann wartet die Read Methode unendlich lange und bekommt nicht mit, wenn neue Daten eintreffen. Das Timeout wird wohl nur iSeries-Seitig gepflegt.

Wir haben nun einen Control Thread eingeaut der prüft, wie lange keine Daten mehr gelesen wurden. Bei einem Timeout wird dann der Read-Thread abgebrochen.

Hier gibt es allerdings noch ungereimtheiten, weil der Thread oft sehr lange brauch um zu terminieren-

Nach dem stoppen versuchen wir uns ab- und anzumelden und starten den Read-Thread erneut.

Interessant klingt auch die Methode mit der Shutdown Message in der Queue.

Gibt es auch noch andere Wege mitzubekommen, wann die Maschine eine Zwangsabmeldung durchführt?

Schönen Abend,

Louis Haußknecht

[BenderD]

Hallo,

ich kenne die .net Methoden nicht aus eigener Erfahrung, bei Java würde ich noch in Betracht ziehen von DataQ auf SQL mit stored Procedures umzusteigen, das scheint mir im Schnitt stabiler zu sein. Das, was Sie als Zwangsabmeldung bezeichnen dürfte m.E. bei einer Sicherung nicht eintreten und wenn man sicher wieß, dass die Sicherung der Auslöser ist, dann würde ich den Dienst für diese Zeit beenden, soweit das von den Rahmenbedingungen möglich ist.

mfg

Dieter Bender

Hallo Herr Bender,

vielen Dank für die Infos.

Wir sind zwar nicht an .net gebunden, aber die ganze Applikation umzuschreiben ist dann doch zu viel Aufwand.

Ich habe hier im Java Forum auch gelesen, dass es Probleme gibt mit dem Timeout beim Read einer DataQueue. Wenn mein DataQueue Objekt auf Daten wartet und dann auf dem System ein Backup durchgeführt wird, dann wartet die Read Methode unendlich lange und bekommt nicht mit, wenn neue Daten eintreffen. Das Timeout wird wohl nur iSeries-Seitig gepflegt.

Wir haben nun einen Control Thread eingeaut der prüft, wie lange keine Daten mehr gelesen wurden. Bei einem Timeout wird dann der Read-Thread abgebrochen.

Hier gibt es allerdings noch ungereimtheiten, weil der Thread oft sehr lange brauch um zu terminieren-

Nach dem stoppen versuchen wir uns ab- und anzumelden und starten den Read-Thread erneut.

Interessant klingt auch die Methode mit der Shutdown Message in der Queue.

Gibt es auch noch andere Wege mitzubekommen, wann die Maschine eine Zwangsabmeldung durchführt?

Schönen Abend,

Louis Haußknecht

[Fuerchau]

Das Problem von .net beim Stoppen von Threads ist, dass der Thread selber auf die Exception reagieren muss und diese sogar ggf. ablehnen kann.
"Hängt" der Thread aber auf der DTAQ, kann auch fast gar nicht auf die Exception reagiert werden (daher die lange Zeit).
Ein richtige "Killen" eines Threads gibts in .net überhaupt nicht mehr !
Wenn du da die Windows-API verwendest, kommt .net mit seiner Speicherverwaltung (Garbage) durcheinander und hinterläßt ggf. große Speicherlücken.

Andererseits kann eigentlich die DTAQ nicht gesichert werden, wenn noch ein Read darauf hängt (Sichern im aktiven Zustand geht für DTAQ's meines Wissens nach nicht).

Werden denn die Hostservices beim Backup runtergefahren ?

Dann könnte man ggf. mittels SQL-Connection die Verbindung überwachen und auf ein Error/Close-Ereignis reagieren.

[ParkerLouis]

Hallo zusammen,

Vorgabe ist, DataQueues zu nutzen. Die werden vom Kunden zur Verfügung gestellt.
Deshalb kann ich auch keine StoredProcedures einsetzen. Übrigens würde das nicht nur durch laufendes Polling und Aufrufen der Proc das gleiche Verhalten wie eine DataQue ermöglichen?

Wir versuchen gerade das Ganze zu entzerren und bauen für den lesenden Zugriff einen Dienst, der dann nach einem Timeout neu gestartet wird. Das ist dann die harte Variante, unschön aber funktioniert dann halt.

Leider lehnt der Kunde es ab, einfach eine Shutdown Message in die Queue zu schreiben. Das wäre meiner Meinung nach noch das schönste. Dann könnte ich nach diesem Read den Thread regulär beenden. Da aber noch Dritte an der Schnittstelle hängen möchte man sich wohl Abstimmungen sparen.

Wie genau das "Abhängen" unseres Dienstes auf AS/400 Seite funktioniert ist mir nicht klar und wir haben da auch keine Einsicht.

Eine Frage habe ich noch: Kann es sein, dass es Probleme gibt, wenn man in einem Thread im Read() steht und gleichzeitig aus einem anderen Thread einen Write() durchführen will? Beide Queues nutzen das gleiche AS400 Objekt.

Ich bin mir sicher, dass das Write richtig durchläuft, aber der Kunde sagt, er bekommt keine Daten auf AS400 Seite.

Übrigens bin ich sehr überrascht, über die netten Antworten! Danke!

Louis Haußknecht

[BenderD]

Hallo,

grundsätzlich würde ich mich bei DataQ Objekten nicht auf korrekte Funktion im Multithreading verlassen wollen!!! Deshalb hatte ich auch stored Procedures genannt, was sicherlich Auswirkungen auf die Architektur der Lösung gehabt hätte.

Die Hypothese mit der Sicherung ist für mich noch schwach, da scheint mir ducrchaus noch Klärungsbedarf - und wenn der Kunde den nicht sieht und gleichzeitig Vorgaben macht, dann muss er wohl mit den Konsequenzen leben.

mfg

Dieter Bender

Hallo zusammen,

Vorgabe ist, DataQueues zu nutzen. Die werden vom Kunden zur Verfügung gestellt.
Deshalb kann ich auch keine StoredProcedures einsetzen. Übrigens würde das nicht nur durch laufendes Polling und Aufrufen der Proc das gleiche Verhalten wie eine DataQue ermöglichen?

Wir versuchen gerade das Ganze zu entzerren und bauen für den lesenden Zugriff einen Dienst, der dann nach einem Timeout neu gestartet wird. Das ist dann die harte Variante, unschön aber funktioniert dann halt.

Leider lehnt der Kunde es ab, einfach eine Shutdown Message in die Queue zu schreiben. Das wäre meiner Meinung nach noch das schönste. Dann könnte ich nach diesem Read den Thread regulär beenden. Da aber noch Dritte an der Schnittstelle hängen möchte man sich wohl Abstimmungen sparen.

Wie genau das "Abhängen" unseres Dienstes auf AS/400 Seite funktioniert ist mir nicht klar und wir haben da auch keine Einsicht.

Eine Frage habe ich noch: Kann es sein, dass es Probleme gibt, wenn man in einem Thread im Read() steht und gleichzeitig aus einem anderen Thread einen Write() durchführen will? Beide Queues nutzen das gleiche AS400 Objekt.

Ich bin mir sicher, dass das Write richtig durchläuft, aber der Kunde sagt, er bekommt keine Daten auf AS400 Seite.

Übrigens bin ich sehr überrascht, über die netten Antworten! Danke!

Louis Haußknecht

[ParkerLouis]

Ist es denn legitim, in einem Prozess mehrere AS400 Objekte aufzumachen, die sich dann auch alle an der Maschine anmelden? Klingt ja nicht richtig resourcensparend, aber wir brauchen einen gangbaren Weg dafür.

[BenderD]

ich kann das immer nur aus der Java Perspektive beantworten: jedes DataQ Objekt repräsentiert einen Server Job, der immer nur eine Anforderung nach der anderen verarbeitet; ein Lese Thread mit einem langen Wait braucht also eine eigene Connection, wenn man das vermeiden will, müsste man auf Socket Verbiondungen umsteigen (was nicht zur Anforderung passt). Optimieren kann man die Mehrfach Verbindungen durch einen Pool (was Java angeht, taugen die von der Toolbox nix).

Ist es denn legitim, in einem Prozess mehrere AS400 Objekte aufzumachen, die sich dann auch alle an der Maschine anmelden? Klingt ja nicht richtig resourcensparend, aber wir brauchen einen gangbaren Weg dafür.

[ParkerLouis]

Okay, ich sehe schon. Beim nächsten Projekt wird Java für die direkte SChnittstelle zur AS/400 genommen. Da gibt es deutlich mehr Resourcen für im Netz.

Die jetzigen Probleme werde ich dann durch Trennung der Prozesse (und ggf. Neustart des lesenden Prozesses) und einer Connection pro Queue umbauen.

Vielen Dank für Eure Hilfe,

ich werde noch mal berichten, wie das System weiter läuft.

Louis