jvm ist im native code nicht zerstörbar?

[miaumiau]

Hallo, ich habe eine Anwendnung die über das Netzwerk Dateioperationen macht. Wie z.B File.list() File.exists()... Leider ist das Netzwerk so groß und schlecht verdrahtet dass es vorkommen kann dass ein Netzwerk Rechner schon mal eine halbe Std. braucht bis eine Antwort kommt. In dieser Zeit lässt sich die JVM nicht beenden. Das BS ist Windows 2000 prof.

Ich habe folgende Varianten versucht.:

- I/O Operationen in Thread auslagern und diesen als deamon setzen

-Thread probieren mit stop zu beenden

-Thread mit invoke() aufwecken

-I/O Operationen mit ExecutorService und Timeout ausgestattet

- System.exit()

Weiterhin wenn ich im DebuggerModus unter Eclipse arbeitet und den Knopf terminate drücke, kommt der Fehler "Terminate failed"

Im Task-Manager kommt der Fehler "Prozess lässt sich nicht beenden. Zugriff verweigert"

Hat jemand von euch ne Idee wie ich ein beenden der JVM erzwingen kann, egal wie...

Danke euch alle schonmal

[VaNaTiC]

... Wie z.B File.list() File.exists()... Leider ist das Netzwerk so groß und schlecht verdrahtet dass es vorkommen kann dass ein Netzwerk Rechner schon mal eine halbe Std. braucht bis eine Antwort kommt.

Auweia, was ist denn das Problem? Das klingt ja ziemlich heftig und unbenutzbar. Was ist das für ein Netzwerk (Protokoll, ...) wo Timeouts größer 30 Minuten akzeptiert werden?

In dieser Zeit lässt sich die JVM nicht beenden. Das BS ist Windows 2000 prof.

OK aus Deinen diversen Tests lässt sich erahnen, dass nicht die JVM das Problem ist, sondern wahrscheinlich ein durch die JVM eingebundener Systemaufruf des Betriebssystems. Aber die Standardoperationen, wie File.list(), ..., gehen zum Beispiel auch ohne Probleme über das SMB-Protokoll (Teil der Windows Netzwerk Dienste). Wenn ich aber zum Beispiel eine User-Autorisierung auf dem Ziel-Rechner benötige, dann kann das an dieser Stelle der I/O-Aufruf blockieren.

- I/O Operationen in Thread auslagern und diesen als deamon setzen

nette Idee, aber wenn Du die JVM nicht beenden kannst, kann die JVM sich auch nicht selbst beenden, wenn nur noch deamons laufen

-Thread probieren mit stop zu beenden

Thread.stop() ist schon länger deprecated und das ist auch gut so, gewöhn Dir das nicht erst an

-Thread mit invoke() aufwecken

invoke()? aufwecken? nene, resume()=weitermachen, suspend()=anhalten, interrupt()=unterbrechen

-I/O Operationen mit ExecutorService und Timeout ausgestattet

- System.exit()

war klar, dass das nix bringt, wenn Du nichtmal im TaskManager das Ding killen kannst.

Weiterhin wenn ich im DebuggerModus unter Eclipse arbeitet und den Knopf terminate drücke, kommt der Fehler "Terminate failed"

das is sanfter wie die folgende Methode

Im Task-Manager kommt der Fehler "Prozess lässt sich nicht beenden. Zugriff verweigert"

das klingt - wie oben schon gesagt - nicht gut

Irgendwas mit hohen Rechten, wie "System" oder "Kernel" blockiert da, so dass Du mit Userrechten diesen Teil nicht beenden kannst.

Hat jemand von euch ne Idee wie ich ein beenden der JVM erzwingen kann, egal wie...

Das hat wirklich nix mit der JVM zu tun, eventuell hilft Dir, wenn Du Deinem User Debug-Rechte und System-Rechte gibst, aber ich glaubs fast nicht.

Vielleicht hilft Dir eine Suche "task killen trotz Zugriff verweigert"

Fakt ist aber, dass Du damit nicht das Problem des 30-Minuten-Netzwerkes löst.

Bearbeitet 10. März 2009 von VaNaTiC

[miaumiau]

hm also ich greif auf die Files via Windows UNC Pfad zu. Also \\server\freigabe

Es ist nicht mal ein PW gesetzt, aber ich glaube dass es bei solchen Sachen keinen Timeout gibt. Wenn ich mit dem Explorer die Adresse öffne friert der auch so lange ein bis er eine Antwort bekommt...

Eigentlich heißt es doch immer, dass man beim entwickeln von solcher Software die Dateien übers Netzwerk schickt, keine Sorgen um deren Verteilung machen muss, aber das wird mir wohl grade zum verhängnis.

Ich hätte gern mehr Kontrolle über die Verbindung.

Gibts denn Methoden File.list() File.exists() zu umgehen?

Problem bei dem Netzwerk ist, dass es eigentlich mehrere Netzwerke sind,die nur an sehr wenigen Stellen verbunden sind, und wenn man dann einzige solche Brücken überqueren muss passiert sowas wohl

Danke schonmal

[VaNaTiC]

OK, das Netzwerk istt defintiv ein Problem, wenn Du schon sichtbar erkennst, dass es Engpässe hat.

Aha, war meine Vermutung doch richtig.

Freigaben im Windows Netzwerk laufen über netbios (ich hoffe es ist die Standardeinstellung Netbios über TCP/IP) und über das so genannte SMB-Protokoll.

Alles nach Windows 98 und alles ab Windows NT haben keine Netzwerkfreigabe auf freigabeebene, sondern man muss sich tatsächlich mit einem auf dem Zielsystem bekannten User/Pass anmelden.

Sonst geht das sowieso nicht.

So und nun kommt noch hinzu, dass wenn du statt \\192.168.1.x\Freigabe

einen Namen benutzt, wie \\Rechner\Freigabe, dann kommt noch die tolle Namensauflösung mit Netbios dazu. Gerade das und das so genannte Browsing der Freigaben im Netz ist immer wieder der Grund, warum der PC nich in der Windows Netzwerkumgebung is oder warum er den nich findet, oder das es lange dauert, ...

Es gibt diverse Möglichkeiten das zu verbessern:

- in allen Clients einen WINS-Server eintragen und den natürlich wirklich von einem Windows Server machen lassen,

- DNS korrekt eintragen oder wenns nicht zuviel Aufwand is, gleich die IPs und Namen in der hosts oder lmhosts eintragen

- User über Domain oder AD verwalten

Und nun sind wir beim ganz normalen Wahnsinn angekommen

Eine ganz andere Sache ist, dann mit JAVA über die File-I/O-Dienste auf Windows Netzwerkfreigaben zuzugreifen.

Schau Dir mal spaßeshalber sowieso bitte das New-IO-package an.

Und wenns geht versuche doch die Netzwerkdateien tatsächlich von einem extra dafür konzipierten netzwerkprotokoll machen.

Stichwort: FTP oder NFS.

[miaumiau]

ah gut danke für die aufklärung. Ich glaub nciht das nio mich irgendwie weiter bringen wird? Außer halt dann nio2, aber das ist ja alles noch Zukunft.

Eine Frage habe ich noch, ich habe nun vor das Programm zu spalten, alle diese Fileabfragen in ne Art Server zu packen der immer läuft und an einer etwas günstigern Position im Netzwerk steht. Und nur die GUI als Client laufen zu lassen.

Nun hat natürlich der Anwender absolut gar keinen Einfluss mehr auf den Server, daher muss dieser bombenstabil laufen...

Wenn ich jetzt meine berüchtigten File.list() aufrufe starte und der ganze Thread auf das Ergebnis der native Seite wartet, kann ich sicher sein das die nativ Seite ewig weiter probiert den Pc zu erreichen, oder denkt sich diese Windows native Geschichte auch irgendwann dass sie lieber chillen will und n Nickerchen macht?

Leider gehen andere Protokolle nicht da es doch einige 100 Rechner sind und der Verwaltungsaufwand zu groß wär,wobei man sich auf lange sich doch viel sparen würde, aber so wies aussieht wird das in näheren Zukunft nicht eintrefen.

Also lieber Symptom-Bewaldlungs SW-Engineering

Alternativ wär natürlich ne dll basteln und dort die Funktionen nach meinen Wünschen gestalten, jedoch bin ich da nicht so fit, und sollte eher nur die Notlöung sein...

Freu mich auf Antwort

Danke

p.s ich sprech die Kisten sogar über IP Adressen an, aber scheinbar braucht es trotzdem ewig,manchmal...

Bearbeitet 13. März 2009 von miaumiau

[VaNaTiC]

Wenn ich jetzt meine berüchtigten File.list() aufrufe starte und der ganze Thread auf das Ergebnis der native Seite wartet, kann ich sicher sein das die nativ Seite ewig weiter probiert den Pc zu erreichen, oder denkt sich diese Windows native Geschichte auch irgendwann dass sie lieber chillen will und n Nickerchen macht?

Tut mir leid, ich glaube das kann ich Dir keiner beantworten. Obwohl ich sowas hasse, muss ich Dir sagen, dass Du das tatsächlich mal am Echtsystem ausprobieren musst.

Solange Du aber nicht weisst, wieso Dein Netzwerk so reagiert, kann das nur ein "Workaround" sein, kein "Fix". Und für ein Echtsystem sollte man immer einen Fix anstreben.

Leider gehen andere Protokolle nicht da es doch einige 100 Rechner sind und der Verwaltungsaufwand zu groß wär,wobei man sich auf lange sich doch viel sparen würde, aber so wies aussieht wird das in näheren Zukunft nicht eintrefen.

Ich verstehe Dich nur zu gut. Das ist oft eine total schwachsinnige und an den falschen Kompetenzstellen getroffene Entscheidung.

Auch auf die Gefahr hin dass ich mich wiederhole: ohne konkrete Problemanalyse, kein zufriedenstellendes Ergebnis. Eventuell hilft ein wenig Schwarzmalerei für die Kaufmänner

Alternativ wär natürlich ne dll basteln und dort die Funktionen nach meinen Wünschen gestalten, jedoch bin ich da nicht so fit, und sollte eher nur die Notlöung sein...

Wenn Deine Voranalysen stimmen, solltest Du Dir eingestehen, dass das auch nix bringen wird, denn JVM greift auch nur auf die WinAPI zu, genauso wie Du das mit einer DLL machen würdest.

Analysieren solltest Du unbedingt "von Hand" was Deine JVM da im Hintergrund versucht!

Wenn Du neue Erkenntnisse hast würd ich mich über ein Feedback freuen.