View Full Version : Threads per RMI
Hallo liebe Wissenden,
zur Zeit stehe ich vor folgendem Problem:
Ein Java Programm hat die Aufgabe, auf dem PC Threads zu erzeugen, welche über ein RMI-Interface per DTAQs Daten aus der AS400 anfordern. Die Sätze werden durch ein RPGLE dem Java-PGM zur Verfügung gestellt.
Soweit funktioniert auch alles, jedoch nur bis zu einer gewissen Anzahl von anfragenden Threads: Bei ca. 100 aktiven Threads enden einige mit dem folgendem Fehler:
java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
java.net.SocketException: Connection reset by peer: socket write error
at sun.rmi.transport.tcp.TCPChannel.createConnection( TCPChannel.java:291)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCP Channel.java:188)
...
Scheinbar ist die „große“(?!) Anzahl von anfragenden Threads als Ursache anzusehen. Doch auf welcher Seite ist der Fehler zu finden, welche der beteiligten Komponenten schwächelt hier, Java, Windows, oder gar die AS/400? Warum "reset by peer"? Oder sollte ich sogar die grundsätzliche Struktur in Frage stellen?
Hallo,
wer hockt da auf der DTAQ? ein Java Programm? wie werden die Daten per RPGLE bereit gestellt? Falls das synchron mit Java kommuniziert tippe ich auf threading Probleme. Vielleicht kannst du mal genauer beschreiben, was du da machst.
mfg
Dieter Bender
Hallo liebe Wissenden,
zur Zeit stehe ich vor folgendem Problem:
Ein Java Programm hat die Aufgabe, auf dem PC Threads zu erzeugen, welche über ein RMI-Interface per DTAQs Daten aus der AS400 anfordern. Die Sätze werden durch ein RPGLE dem Java-PGM zur Verfügung gestellt.
Soweit funktioniert auch alles, jedoch nur bis zu einer gewissen Anzahl von anfragenden Threads: Bei ca. 100 aktiven Threads enden einige mit dem folgendem Fehler:
java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is:
java.net.SocketException: Connection reset by peer: socket write error
at sun.rmi.transport.tcp.TCPChannel.createConnection( TCPChannel.java:291)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCP Channel.java:188)
...
Scheinbar ist die ?große?(?!) Anzahl von anfragenden Threads als Ursache anzusehen. Doch auf welcher Seite ist der Fehler zu finden, welche der beteiligten Komponenten schwächelt hier, Java, Windows, oder gar die AS/400? Warum "reset by peer"? Oder sollte ich sogar die grundsätzliche Struktur in Frage stellen?
Ok, also der grundsätzliche Ablauf beim Anfragen an die AS/400 ist ungefähr so:
Auf der AS400 laufen permanent 10 Jobs, denen jeweils zwei DTAQs zugeordnet sind.
Max. 10 aktive Jobs sind hierbei zulässig - mit je einer DTAQ zum Empfang und einer für die Antwort. Das ILE dieser Jobs versucht dabei ständig Daten aus der "Anfrage"-DTAQ zu lesen.
Soll nun eine Anfrage an die AS gestellt werden, dann ermittelt Java (jeder Vorgang ein Thread) zunächst, ob eine freie Anfrage-DTAQ zur Verfügung steht (Überwachung der offenen Vorgänge). Ggf. wird hier so lange gewartet, bis dies der Fall ist. Sobald eine DTAQ frei ist, wird sie mit dem Anfrage-String gefüllt. Sodann wird versucht, aus der entsprechende "Antwort"-DTAQ zu lesen.
ILE wiederum stellt fest, dass nun tatsächlich Anfragedaten vorliegen, (ruft nachgeordnete Verarbeitungsprogramme auf) und stellt das Ergebnis in die "Antwort- DTAQ" des Jobs.
Java wartet ja sowieso schon auf die Antwort und that´s it. Im Prinzip auch ok, wenn nur dieser Einbruch bei "vielen" Anfrage-Threads nicht wäre – Blöd!
Andreas
Hallo Andi,
sorry, dass es mit der Antwortzeit etwas zäh zugeht, aber ab und an muss ich mich auch um fakturierbare Dinge kümmern,...
Oder sollte ich sogar die grundsätzliche Struktur in Frage stellen?
Vielleicht nicht das verkehrteste: warum holst du die Daten nicht einfach per JDBC? einen Connection Pool dazwischen gelegt, für jeden Thread eine Connection vom Pool holen und lesen. Wenn es denn wirklich dazwischen noch ein RPG Programm geben muss (was eher stört) dann kann man das als stored Procedure registrieren und per CallableStatement aufrufen.
Der Schwachpunkt der ganzen Sache liegt ind er Komplexität und vermutlich in den Toolbox Komponenten, soweit du keinen Fehler im Threading hast.
mfg
Dieter Bender
Hallo Dieter,
allright vielleicht sollten hierzu tatsächlich Alternativen geprüft. werden. Ich danke trotzdem für deine Mühe
Andreas