BMAS Geschrieben 17. April 2003 Geschrieben 17. April 2003 Kann jemand was damit anfangen? Habe jetzt einfach, mal den Port 1111 genommen, mit dem Standardport(1099) wird dieselbe Exception geworfen. java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1111 connect,resolve) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) at java.lang.SecurityManager.checkConnect(SecurityManager.java:1044) at java.net.Socket.connect(Socket.java:420) at java.net.Socket.connect(Socket.java:376) at java.net.Socket.<init>(Socket.java:291) at java.net.Socket.<init>(Socket.java:119) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128) at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171) at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:313) at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source) at java.rmi.Naming.rebind(Naming.java:160) at com.bmw.nl_muc.ldv.server.impl.LDVServer.<init>(LDVServer.java:42) at com.bmw.nl_muc.ldv.server.impl.LDVServer.main(LDVServer.java:82)
Jaraz Geschrieben 17. April 2003 Geschrieben 17. April 2003 Hi, du hast entweder keine, eine falsche oder an einem falschen Ort liegende java policy Datei. Du brauchst eine Datei mit zumindest folgenden Inhalt. (Das öffnet alle höheren Ports.) Datei: java.policy Inhalt: ---------------------- grant { permission java.net.SocketPermission "*:1024-65535", "connect,accept,resolve"; permission java.security.AllPermission "",""; }; ---------------------- Außerdem musst du der JVM beim Start sagen, wo sie diese Datei findet. java.exe -classpath "./bin" -Djava.security.policy=java.policy com.package.Klasse Gruß Jaraz
BMAS Geschrieben 17. April 2003 Autor Geschrieben 17. April 2003 Danke! Ja, das war es, hattest du mir auch damals in der Mail geschrieben, habe ich nur vergessen... :floet: Aber jetzt kriege ich das: java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use: JVM_Bind at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:243) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:178) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:145) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:78) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:164) at com.bmw.nl_muc.ldv.server.impl.LDVServer.<init>(LDVServer.java:41) at com.bmw.nl_muc.ldv.server.impl.LDVServer.main(LDVServer.java:82) Caused by: java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331) at java.net.ServerSocket.bind(ServerSocket.java:309) at java.net.ServerSocket.<init>(ServerSocket.java:183) at java.net.ServerSocket.<init>(ServerSocket.java:95) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333) at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:615) at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:231) ... 9 more Ich starte den Server und danach den Client, beide auf einem Rechner. Normalerweise sollte das doch gehen oder? Neija, ich werde mir das heute Abend nochmal anschauen, jetzt habe ich erstmal Prüfungsvorbereitung... Frohe Ostern!
PerdianMG Geschrieben 18. April 2003 Geschrieben 18. April 2003 Aber jetzt kriege ich das: java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use: JVM_Bind Ich starte den Server und danach den Client, beide auf einem Rechner. Normalerweise sollte das doch gehen oder? Normalerweise schon aber sie dir mal die Exception an, da steht ja schon alles drin, was du wissen musst: "Port already in use". Also entweder startes du dein Programm 2x und willst daher 2x den Port belegen (geht natürlich nicht) oder du hast auf Port 1099 noch irgendeinen anderen Dienst laufen und deshalb geht nix. Ciao Christian
BMAS Geschrieben 18. April 2003 Autor Geschrieben 18. April 2003 Hmm, nein ich starte das Programm nicht 2x, wenn ich den Server starte kommt keine Exception, wenn ich dazu noch den Client starte kommt die Exception... Ich habe es auch schon mit mehreren anderen Ports probiert.
Jaraz Geschrieben 18. April 2003 Geschrieben 18. April 2003 Hi, die RMIRegistry wird insgesammt nur auf einem Rechner benötigt. Du kannst Sie mit dem eigenständigen Programm rmiregistry im bin Verzeichnis des JDK oder direkt aus einem eigenen Java Programm heraus starten: LocateRegistry.createRegistry(1099); Das aber auf einem Port nur einmal. Sinnvollerweise durch den Server. Dann musst du egal ob die registry nun als eigenständiger Systemprozess oder als Java Thread läuft, das Serverobjekt an der Registry binden. Naming.bind("rmi://"+host+":"+port+"/Server", serverObjekt); Der Client kann sich nun "das Serverobjekt" von der einen rmiregistry die der Server gestartet hat, holen. server = (ServerInterface) Naming.lookup("rmi://"+host+":"+port+"/Server"); Solltest du die rmiregistry in deinem Programm starten, läuft sie solange, bis der aufrufende Thread beendet wird. Die Exeption beruht imho eindeutig darauf, das schon was auf Port 1099 läuft. Und wenn es eine extern gestartete rmiregistry ist. Startest du sie vielleicht von der eclipse Preferences Seite zu RMI und dann nochmal im Programm selbst? Gruß Jaraz
BMAS Geschrieben 19. April 2003 Autor Geschrieben 19. April 2003 Also so langsam zweifele ich wirklich an meinem Verstand ... ich habe jetzt mal nachgeschaut in Eclipse unter Preferences habe ich keine Registry gestartet. Wenn ich den Server starte und dieser eine Registry erstellt, steht unter Preferences "1 Remote Object registered" oder so ähnlich. Starte ich dann den Client wird wieder die Exception geworfen... Ich habe inzwischen schon mit zig verschiedenen Ports versucht und bin langsam echt am verzweifeln. @Jaraz Mit dem PZEServer und dem PZEClient passiert genau dasselbe! :eek:
Jaraz Geschrieben 19. April 2003 Geschrieben 19. April 2003 Original geschrieben von BMAS @Jaraz Mit dem PZEServer und dem PZEClient passiert genau dasselbe! :eek: Ohne das du was geändert hast? Da würde mich schwer wundern. Habe die Mail gerade noch mal herausgesucht und das was ich dir geschickt habe, getestet. Läuft ohne Probleme. Gruß Jaraz
BMAS Geschrieben 19. April 2003 Autor Geschrieben 19. April 2003 Ich habe den Fehler gefunden, mein Eclipse war total kaputt und wollte vorhin nichtmal mehr starten, nach der Neuinstallation ging sogar mein Programm (und der PZEServer natürlich auch)! Blöde EDV!
BMAS Geschrieben 20. April 2003 Autor Geschrieben 20. April 2003 Was mich noch interessieren würde. Muss ich irgendwas beachten, wenn der Server den Clients ,über RMI, Methoden zur Verfügung stellt um auf eine DB zuzugreifen? Muss da irgendwas synchronisiert werden? Oder wird das automatisch gemacht? Wenn ich also einfach den Code deines PZEServers nehmen würde. Da noch ein paar Methoden implementieren würde, die den Zugriff auf eine DB erlauben und mehrere Client starte die diese gleichzeitig benutzen. Kann das dann zu inkonsistenten Datensätzen führen? Wenn Ja, wie kann ich das verhindern?
SgtBadAzz Geschrieben 22. April 2003 Geschrieben 22. April 2003 Original geschrieben von BMAS Was mich noch interessieren würde. Muss ich irgendwas beachten, wenn der Server den Clients ,über RMI, Methoden zur Verfügung stellt um auf eine DB zuzugreifen? Muss da irgendwas synchronisiert werden? Oder wird das automatisch gemacht? Wenn ich also einfach den Code deines PZEServers nehmen würde. Da noch ein paar Methoden implementieren würde, die den Zugriff auf eine DB erlauben und mehrere Client starte die diese gleichzeitig benutzen. Kann das dann zu inkonsistenten Datensätzen führen? Wenn Ja, wie kann ich das verhindern? RMI uebernimmt nicht die Verantwortung wenn deine Datenbank inkonsistent wird. Das kann man ueber Transaktionen regeln, wenn die DB das kann. Es gibt pessimistic und optimistic locking und entsprechende isolation levels, sieh mal im internet nach oder in der DB doku oder in entsprechender Literatur. Frank
Jaraz Geschrieben 22. April 2003 Geschrieben 22. April 2003 Hi, RMI startet eigene Threads für die RemoteObjekte die sich anmelden. Du musst also im großen und ganzen darauf achten, dass alle lesenden und schreibenen Zugriffe auf gemeinsam genutzte Daten (Objekte) mit synchronized realisiert werden, falls zumindest ein Thread die Daten verändert. Datenbankinkonsistenzen kannst du durch Transaktionen vermeiden. Gruß Jaraz
SgtBadAzz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Original geschrieben von Jaraz Hi, RMI startet eigene Threads für die RemoteObjekte die sich anmelden. Du musst also im großen und ganzen darauf achten, dass alle lesenden und schreibenen Zugriffe auf gemeinsam genutzte Daten (Objekte) mit synchronized realisiert werden, falls zumindest ein Thread die Daten verändert. Datenbankinkonsistenzen kannst du durch Transaktionen vermeiden. Gruß Jaraz Beim Lesen muss ich wohl nichts synchronisieren oder wie darf ich das verstehen ? Frank
Jaraz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Falls ein Thread existiert, der den Zustand eines Objektes ändert, müssen auch die lesenden Methoden synchronisiert werden. Ansonsten kann es passieren, das zwischen den beiden konsistenten Zuständen des Objektes, die vor und nach dem Ausführen einer synchronisierten schreibenen Methode vorhanden sind, ein lesender Thread einen inkonsistenten Zustand des Objektes ausliest. Gruß Jaraz
SgtBadAzz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Original geschrieben von Jaraz Falls ein Thread existiert, der den Zustand eines Objektes ändert, müssen auch die lesenden Methoden synchronisiert werden. Ansonsten kann es passieren, das zwischen den beiden konsistenten Zuständen des Objektes, die vor und nach dem Ausführen einer synchronisierten schreibenen Methode vorhanden sind, ein lesender Thread einen inkonsistenten Zustand des Objektes ausliest. Gruß Jaraz Entweder das Objekt hat den Wert a oder den Wert b , und je wann ich lese bekomme ich eben a oder b. Und was ist denn ein Objekt inkonsistent ? Es ist eher so, dass man lesen fast nie synchronisiert um keine Bottlenecks zu erzeugen man isoliert aber teilweise das Schreiben, siehe hierzu auch Isolation levels bei DB'S. Frank
Jaraz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Original geschrieben von SgtBadAzz Entweder das Objekt hat den Wert a oder den Wert b , und je wann ich lese bekomme ich eben a oder b. Aha, bei mir haben Objekte eher Zustände, da sie aus mehreren Attributen oder Referenzen auf andere Objekte bestehen. Um von Zustand a nach b zu kommen, können verschiedene Operationen nötig sein. Wenn nun zwischen diesen Zuständen ein Thread lesend zugreift, bekommt er nicht Werte von a oder b, sondern irgendwas dazwischen. Gruß Jaraz
SgtBadAzz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Original geschrieben von Jaraz Aha, bei mir haben Objekte eher Zustände, da sie aus mehreren Attributen oder Referenzen auf andere Objekte bestehen. Um von Zustand a nach b zu kommen, können verschiedene Operationen nötig sein. Wenn nun zwischen diesen Zuständen ein Thread lesend zugreift, bekommt er nicht Werte von a oder b, sondern irgendwas dazwischen. Gruß Jaraz Dann muss es aber einen single point of entry geben der das Objekt managed und nicht nur einzelne Methoden die synchronisiert werden. Es kann ja durchaus sein, dass ich ein Attribut aendere die anderen aber nicht und wenn ich das ganze ding dann auf locked setze und nicht mehr zurueck setze dann kann ich ja nie mehr was lesen. Frank
Jaraz Geschrieben 23. April 2003 Geschrieben 23. April 2003 Original geschrieben von SgtBadAzz Es kann ja durchaus sein, dass ich ein Attribut aendere die anderen aber nicht und wenn ich das ganze ding dann auf locked setze und nicht mehr zurueck setze dann kann ich ja nie mehr was lesen. Verklemmungen können aber generell auftreten, auch bei nur nicht-lesenden synchronized Methoden. Da muss man bei jedem Sperrmechanismuss aufpassen. Auf alle Fälle gilt, wenn man mit synchronized arbeitet, sollte man schreibene und lesende Methoden als synchronized deklarieren. Wenn nämlich keine Inkonsistenz eintreten kann, brauch man auch kein synchronized. Wenn es aber zu Inkonsistenzen kommen kann, dann auch beim lesenden Zugriff. Gruß Jaraz Und da das ganze nichts mit RMI mehr zu tun hat, mache ich hier jetzt zu. Wenn jemand weiter über Java Threads diskutieren will, kann er gerne nen Thread dafür aufmachen.
Empfohlene Beiträge