RMI delay windows(client) <-> linux(server)

Status
Nicht offen für weitere Antworten.

Tallan

Bekanntes Mitglied
Hallo zusammen,

mir ist fogledens aufgefallen.

Ich habe einen Client und einen Server

Wenn der Server auf einem Linux system läuft benötigt der Client für die erste Anfrage ~5 Sekunden
danach für die selbe oder ähnliche Funktion sogut wie keine Zeit.

Das Problem tritt nur in der Linux-Server, Windows-Client konstellation auf.
Die beiden Rechner hängen um andere Ursachen auszuschließen nur an einem Switch und kommunizieren über statische IP Adressen.
Da Linux auf Linux einwandfrei funktioniert schließe ich probleme mit der jdk version fast aus ( hier habe ich auch mehrere getestet, leider ohne erfolg ).

Hat jemand eine Idee woran das liegen könnte?
 
Meinst du mit "1. anfrage" wirklich den ersten Remote-Call, oder hast du da den Lookup mit eingerechnet?

- Alex
 
In dem Fall wird etwas mehr gemacht, der Client logt sich ein und bekommt daten vom server.
Beim ersten Login dauert es ~5-7 Sekunden. Beim Login eines LinuxClients hat der User keine warnehmbare Wartezeit, ebenso nicht wenn der Server auf Windows läuft, selbst dann nicht wenn die Datenbank weiterhin auf einem 3ten Rechner ( Linux ) liegt.

Es ist daher denke ich irrelevant wieviel die Methode letztendlich macht, zumal es in jedem fall immer exakt das selbe ist und dabei einmal fast instant und in der windows linux Konstellation 5Sekunden + dauert. Wenn ich den User dann abmelde und wieder anmelde entfällt die Wartezeit obwohl hier wieder genau das gleiche passiert, daher vermute ich das es ein Problem bei der ersten Kontaktaufnahme gibt.
 
Also um das nochmal zusammenzufassen:

Windows Client + Linux Server:

Client startet das erste mal und macht den Lookup: Dauert ca. 5sek.
Client wird beendet und nochmal gestartet: Diesmal dauerts keine 5sek.

Richtig so?

In dem Fall: Hmm, verdammt gute frage ... Du könntest in mal (in Windows) mit TCPView (google hilft) schauen was auf Socketebene so passiert. Evtl. gibts ja Handshake-Probleme.

Hat der Linuxrechner ne Firewall laufen?

Könntest auch mal Linux Client und Windows server probieren...
 
Also um das nochmal zusammenzufassen:

Windows Client + Linux Server:

Client startet das erste mal und macht den Lookup: Dauert ca. 5sek.
Client wird beendet und nochmal gestartet: Diesmal dauerts keine 5sek.

Richtig so?

In dem Fall: Hmm, verdammt gute frage ... Du könntest in mal (in Windows) mit TCPView (google hilft) schauen was auf Socketebene so passiert. Evtl. gibts ja Handshake-Probleme.

Hat der Linuxrechner ne Firewall laufen?

Könntest auch mal Linux Client und Windows server probieren...

Nicht ganz

Programm startet, in der GUI kann der User sich auf dem Sever anmelden das dauert 5-7 Sekunden wenn der Client unter Windows läuft und der Server unter Linux.
Wenn der User sich abmeldet( Programm selbst bleibt offen ) und ein neuer User sich anmeldet geschieht die anmeldung quasi instant.
Ebenso bei allen anderen Kombinationen was Windows , Linux, Client und Server angeht ist dieser Login fast instant auch beim ersten mal.
Wenn ich das Programm neu starte läd die Gui ( hier werden die Sockets eigentlich schon aufgebaut )
aber ich rufe noch nichts per rmi selbst auf.
Dann Logt der User sich ein -> 5-7 Sekunden warten der rest ist wieder extrem schnell, selbst methoden die wesentlich mehr an Daten übertragen sind sogut wie instant.
 
Ich tippe da jetzt ebenfalls auf den Lookup von RMI.
Wie tuxedo bereits fragte, ist doch hier die frage WO genau der Delay entsteht. Auf eine Programmzeile herunter gebrochen wird das wohl möglich sein.
Da Du mit RMI arbeitest gehe ich davon aus, dass Du weisst, was mit dem Lookup gemeint ist!?
Zur Sicherheit: Wie lange dauert in etwa ein
Java:
Registry reg = LocateRegistry.getRegistry(host,port);
MyRMIServer server = (MyRMIServer)reg.lookup("MyRMIServer");
 
Der lookup findet bereits beim Programmstart statt, und geht sehr schnell
das eigentlich Problem tritt erst beim ersten Aufruf einer RMI Methode auf.

Das ganze läuft vereinfacht so ab :
ClientProg startet (hierbei wird der lookup schon durchgeführt)
Über die GUI kann der User sich jetzt auf dem Server anmelden ( erstmaliger aufruf einer RMI Methode )
Hierbei geht die GUI in einen Ladestatus bis der Server ihm eine SessionID zuweist. Das dauert im Problemfalls 5-7 Sekunden.
Melde ich den User nun ab und einen anderen an geht dies instant ( hier passiert in der Methode exakt das selbe wobei natürlich eine andere SessionID erstellt wird... )

Wenn ich das Programm ganz schließe und neu starte entsteht wieder die Verzögerung, allerdings nur in der Kombination Windows Cleint - Linux Server in allen anderen möglichen Kombinationen ist die Anmeldung zeitlich für den User fast garnicht zu erfassen.
 
Zuletzt bearbeitet:
Nimm Dir mal wireshark zur Hilfe und schau mal ob der erste Aufruf eine RMI-Methode ein Kommunikationsproblem ist (Pakete brauchen lange bis sie beantwortet werden), oder ob die ersten Pakete lange brauchen bis sie raus gefeuert werden. Oder ob vielleicht noch X andere Netzwerk-Calls zuvor gemacht werden, die anschließend nicht mehr nötig sind (irgendwelche DNS oder ARP Auflösungen usw)
 
Du könntest mal noch auf Serverseite messen wie lange die Methode läuft bis sie das Ergebnis zurück liefert. Vielleicht liegts ja gar nicht an RMI ...

- Alex
 
ich werde den test mit wireshark machen,
@alex an der laufzeit der rmi methoden kann es eigentlich nicht liegen da diese ja in allen anderen fällen sogut wie instant ist
auch mit dem selben server wenn der client ein andere linux rechner ist.
 
Zwischen "kann eigentlich nicht sein" und "ich habs ausprobiert und kanns zu 100,00% ausschließen" können ganze Galaxien liegen.

- Alex
 
ok hat sich erledigt, ich hab grad mit wireshark die verbindung unter die lupe genommen
und der aufruf war wieder instant, allerdings habe ich vorher das linux system noch aktuallisiert wobei hier die jdk und jre ein update bekommen hat das scheint wohl ursache des problems gewesen zu sein.

Trotzdem Viele Dank für die Hilftestellungen.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.

Neue Themen


Zurück
Oben