DTAQ lesen stoppt nach ca. 2-3 Sätzen für 2 Sekunden

[Nili]

Hi!

Ich habe ein Problem mit DTAQ lesen unter Java mit JTopen.
Die DTAQ ist pro Satz 2048 Byte gross und gekeyt.
In einem Thread werden DTAQ Sätze empfangen. Nach ca. 2-3 empfangenden Sätzen bleibt der Thread in der Methode „dq.read()“ für ca. 2 Sekunden stehen, als ob er auf neue Daten wartet. Bloss in der DTAQ stehen noch 20 Sätze drin die zu empfangen wären.

Hat jemand eine Idee woran das liegen kann?

Benutzt wird PC seitig JTOpen 4.5 + Java SDK 1.4.2_5 und die iSeries läuft unter V5R1M0.

Beispiel:

// Thread ….
public void run() {

KeyedDataQueueEntry kdqe = null;

while (!isDone()) {
try {
System.out.println("Nex: " + new
Date(System.currentTimeMillis()));
kdqe = dq.read(dtaqKey, -1, "EQ");
System.out.println("Get: " + new
Date(System.currentTimeMillis()));
}
}
}

Timestamp:

Write: Wed Sep 08 12:22:14 CEST 2004
Write: Wed Sep 08 12:22:14 CEST 2004
Get: Wed Sep 08 12:22:14 CEST 2004
Nex: Wed Sep 08 12:22:14 CEST 2004
Get: Wed Sep 08 12:22:14 CEST 2004
Nex: Wed Sep 08 12:22:14 CEST 2004
Get: Wed Sep 08 12:22:16 CEST 2004 // Hier 2 Sekunden Pause,
Nex: Wed Sep 08 12:22:16 CEST 2004 // danach läuft alle normal
Get: Wed Sep 08 12:22:16 CEST 2004 // weiter.
Nex: Wed Sep 08 12:22:16 CEST 2004

Danke !

[BenderD]

Hallo,


Hi!

Ich habe ein Problem mit DTAQ lesen unter Java mit JTopen.
Die DTAQ ist pro Satz 2048 Byte gross und gekeyt.
In einem Thread werden DTAQ Sätze empfangen. Nach ca. 2-3 empfangenden Sätzen bleibt der Thread in der Methode ?dq.read()? für ca. 2 Sekunden stehen, als ob er auf neue Daten wartet. Bloss in der DTAQ stehen noch 20 Sätze drin die zu empfangen wären.

Hat jemand eine Idee woran das liegen kann?

Danke !

spontan fallen mir 3 Kandidaten ein:
- garbage Collection
- Bug in jtopen
- timestamp ungenau

ersteres könnte man weiter untersuchen durch gezieltes Anstoßen des gc oder durch timestamps in finalize() Methoden, oder vielleicht sollte man der JVM beim Start mal mehr Speicher geben.

zweiteres könnte man untersuchen durch Wechsel der jtopen Version

drittes erscheint mir unwahrscheinlich, so ungenau sollte der Timestamp von System nun auch wieder nicht sein.

Eventuell liegt die Ursache auch AS400 seitig, was ist denn so auf der Möhre los?

mfg

Dieter Bender

[Nili]

Hallo!


Hallo,

spontan fallen mir 3 Kandidaten ein:
- garbage Collection
- Bug in jtopen
- timestamp ungenau

auf der Möhre los?

mfg

Dieter Bender

Trifft alles 3 nicht zu.
GC hab ich mal deaktiviert, keine Verbesserung.
Bug in JTOpen, nee, glaub ich nicht. Hab 3 Versionen durch probiert. Die im JTOpen Forum meinen das liegt an der iSeries,
dem schliess ich mich mal an.

Hab mal nen TRCTCPAPP gemacht und der bringt folgendes zu Tage:

19:40:49.522216 Trace Point: Qzbs1050 Entry Type: 2 Function ID: QzbsReceiveClientReq
000006330000E007 0000000000000023 00160005C7E4C96D C4E3C1D84040D7C5 *......Ö.............GUI_DTAQ PE*
D7D9404040404040 F1F1000005FC5001 F2F64040F0F0F0F0 4040404040404040 *PR 11....&.26 0000 *
4040404040404040 4040404040404040 4040404040404040 4040404040404040 * *
4040404040404040 4040404040404040 4040404040404040 4040404040404040 * *
4040404040404040 4040404040404040 4040404040404040 4040404040404040 * *

19:40:49.522800 Trace Point: Qzbs1060 Entry Type: 2 Function ID: QzbsSendClientReq
000000160000E007 0000000000000023 00028002F000 *......Ö.............0. *
19:40:51.580608 Trace Point: Qzbs1060 Entry Type: 2 Function ID: QzbsSendClientReq
0000084D0000E007 0000000000000021 00268003F0004040 4040404040404040 *...(..Ö.............0. *
4040404040404040 4040404040404040 4040404040404040 4040000008065001 * ....&.*
F2F64040F0F0F0F0 4040C8C4F440F0F1 F0F0F0F4F0F0F1D3 F0F0F14040404040 *26 0000 HD4 010004001L001 *
4040404040C1F0F7 F9F0F04022404040 40404040404040F1 F0F14040C8C1E4D7 * A07900 . 101 HAUP*
E3D4C5D55A005CD4 C5D5E44040404040 D3C9D540F0F1F0F0 F0F1F0F0F1D9F0F0 *TMENÜ.*MENU LIN 010001001R00*
F1D4C5D5E4F1F0F2 404040E3F0F0F7F0 F040204040404040 4040404040F2005C *1MENU102 T00700 . 2.**

Vielleicht noch ein paar andere Ideen?

Danke!