RMI Polling oder lange Verbindungen

[SlaterB]

hallo,

ich habe einen RMI-Server und Clients,
die Clients starten am Server langfristige Aktionen und überwachen deren Status

nun habe ich die Möglichkeit, alle 10 sec am Server den aktuellen Status kurz nachzufragen, dazwischen keine Kommunikation,

oder Anfragen zu stellen, die solange beim Server blockieren, bis das Ergebnis feststeht,
gegegebenfalls wieder nach maximal 10 sec Rückmeldung, wenn z.B. ein informativer Zwischenstand (% verarbeitet) zurückzugeben werden kann,

letzteres gefällt mir besser, da ich eher das Ende eines Prozesses erfahre, wenn dieses nach 2 sec in einem 10 sec-Intervall stattfindet,
ich frage mich aber, ob es da Nachteile zu bedenken gibt, stören die lange offen gehaltenen Verbindungen?
gibt es ein Maximum an Wartezeit/ gleichzeitig offenen Verbindungen? sonst etwas RMI-spezifisches interessant?
dass am Server zusätzliche Threads laufen bzw. warten scheint mir akzeptabel

 

[tuxedo]

Wie wär's mit Callbacks?

Der Server kann sich ja beim Client melden wenn er fertig ist.

Dazu musst du auf Clientseite un Remote-Objekt erstellen (so wie du's auf Serverseite getan hast) und dem Server über einen Methodenaufruf mitgeben. Der Server kann dann, wenn er fertig ist, Methoden in dem Callbackobjekt aufrufen und somit die fertigstellung der Aufgabe dem Client mitteilen.

Ein Code-Snippet hab ich leider nur für SIMON. Aber mit RMI sollte es ähnlich sein:

SIMON - Sample helloworld - root1.de - Software Engineering

Oder etwas flexibler via Annotations:

SIMON - Sample helloworld110 - root1.de - Software Engineering


- Alex

 

[SlaterB]

Callback mag ich nicht weil dann meinem Verständnis nach der Client zum Server wird, was vielleicht durch Firewall oder ähnliches verhindert wird,
ich weiß nicht genug davon um mir sicher zu sein, möchte aber unnötige zusätzliche Komplexität vermeiden

ich sehe das gerne ähnlich zum Web mit http-Anfragen, wo sich ein Callback auch eher nie durchsetzt


hier übrigens ein Beispiel für RMI der Vollständigkeit halber
Threads and Callbacks in RMI

 

[tuxedo]

Callback mag ich nicht weil dann meinem Verständnis nach der Client zum Server wird, was vielleicht durch Firewall oder ähnliches verhindert wird,
ich weiß nicht genug davon um mir sicher zu sein, möchte aber unnötige zusätzliche Komplexität vermeiden

Tja, für den Fall von RMI ist das in der Tat wahr Ich nehme an du hast andere Abhängigkeiten zu RMI die dich vom Wechsel zu SIMON abhalten (root1.de - Software Engineering)

ich sehe das gerne ähnlich zum Web mit http-Anfragen, wo sich ein Callback auch eher nie durchsetzt

Das kommt auf die implementierung an. Wenn die Verbindung zum Webserver dauerhaft offen wäre könnte der Server auch durch Firewalls und Router hindurch Callbacks ausführen. Denn die Verbindung wurde vom Client initiiert.


Gruß
Alex

 

[tuxedo]

Ach ja. Zum Thema Polling oder lange Verbindung:

Wie lange die Verbindung offen bleibt kannst du afaik nicht beeinflussen. RMI handhabt das "irgendwie" intern. Mit einem blockierenden Methodenaufruf, der erst zurückkehrt wenn die Aufgabe erledigt ist, hälst du dir halt auf Serverseite einen Thread offen. Wenn du nicht gerade hunderte/tausende Clients hast wäre das, abgesehen von Callbacks, die wohl beste Lösung die am wenigsten "Stress" auf Serverseite verursacht. Wenn du mit vielen Cliebts ständig pollst, dann hat der Server da mehr zu tun.

Wenn RMI Callbacks also nicht gewünscht sind und ein Wechsel zu SIMON nicht möglich ist, dann würde ich den blockierenden Methodenaufruf wählen.

- Alex

 

[SlaterB]

na dann danke erstmal für deinen Beitrag und die nicht zu offensiven Kauftipps

 

[tuxedo]

[offtopic] Wer hat was von kaufen gesagt?! Ach so... du magst kein GPL?! [/offtopic]