Zitat Zitat von BenderD Beitrag anzeigen
Normalerweise werden die Events jeder für sich in einem separaten Thread abgearbeitet und das geht hier auch nicht anders, ansonsten stirbst du immer wieder diesen Tod, dass das UI einfriert.
Ok also ist mein Problem eigendlich, dass Threads nicht mit CHGACGCDE funktionieren
Zitat Zitat von BenderD Beitrag anzeigen
Wenn die RPG Komponenten zustandslos sind (ich fürchte sie sind es nicht), dann könnte man das relativ schnell abmildern, indem man mehrere Listener auf die DataQ setzt, die dann parallel abarbeiten, aber dann muss die gesamte Synchronisation im "Frontend" stattfinden.
Naja wenn ich ein zustandsloses Backend wollen würde könnte ich auch gleich CGIDEV nehmen...
Zitat Zitat von BenderD Beitrag anzeigen
Was für eine Komponente macht denn die Darstellung und schreibt und liest die DataQ? Ist das Java in einem Tomcat? oder .NET in einem IIS, oder so ein Zauberkasten (wenn ja welcher)?
Der Client verbindet sich per Websocket auf einem Jetty Web-Server auf der AS400, der wiederum RPG-Jobs startet und mit diesen per DTAQ kommuniziert.

Beim Starten wird eine Portal-App gestartet, aus der man weiter Programme Starten kann. Zwischen den einzelnen View's und den Jobs besteht dann immer eine 1 zu 1 verbindung.

Jobs Untereinander können aber auch an andere Jobs über die DTAQ nachrichten schicken.

Über die DTAQ können nicht nur Events verschickt werden sondern auch Prozeduren aufgerufen werden. Hier wird eine Rückantwort verlangt, die dann eine callBack prozedur auslösen kann.

Die geschwindigkeit der VIEW ist bei den bis jetzt umgesetzten Anwendungen recht gut. Aber klar wenn im Programm eine Verarbeitung länger dauert stauen sich die Events auf und werden erst verarbeiten wenn die Verarbeitung gemacht ist.

Vlt sollte ich bei jedem event ein rotes X unten anzeigen und warten bis eine Antwort zurückkommt?