Java - Mehrere Selektoren in mehreren threads für nicht blockierende sockets

Ich Schreibe eine Java Anwendung, mit der Objekte instanziieren einer Klasse repräsentieren Kunden, die angeschlossenen und registrierten mit einem externen system auf der anderen Seite meiner Anwendung.

Jedes client-Objekt hat zwei verschachtelte Klassen innerhalb es, stellvertretend für front-end und back-end. die front-end-Klasse werden kontinuierlich Daten empfangen, die aus den tatsächlichen client, und senden Sie Hinweise und Daten an den back-end-Klasse, die die Daten vom front-end aus und senden Sie es an das externe system in das richtige format und Protokoll, das system erfordert.

In der design -, wir sind auf der Suche, um jede einzelne Instanziierung von einem client-Objekt einen thread. Dann, in jedem thread wird natürlich mit zwei sockets [BEARBEITEN]mit Ihren eigenen NIO-Kanäle[/EDIT], die eine client-Seite, einem system-Seite, die Ihren Wohnsitz in der front - und back-end-bzw. Jedoch, dies stellt nun die Notwendigkeit von nicht blockierenden sockets. Ich lese das tutorial hier, die erklärt, wie man sicher verwenden Sie einen Selektor in der Haupt-thread für den Umgang mit allen threads mit verbindungen.

Aber, was ich brauche, sind mehrere Selektoren-jede in Ihrem eigenen thread. Aus der Lektüre der oben genannten tutorial habe ich gelernt, dass der Schlüssel-sets in einem Selektor sind nicht threadsicher. Bedeutet dies, dass getrennte Selektoren, von denen im eigenen repsective threads erstellen können widersprüchliche Schlüssel, wenn ich versuche, geben Sie Ihnen jeweils Ihre eigenen paar Steckdosen und Kanäle? Bewegen Sie den Wählschalter, bis der Haupt-thread ist eine leichte Möglichkeit, aber weit vom ideal auf Basis der software-Anforderungen, die ich bereits gegeben habe. Danke für Eure Hilfe.

InformationsquelleAutor michael.bartnett | 2009-07-10

3

Verwendung mehrerer Selektoren wäre in Ordnung, solange Sie sich nicht registrieren den gleichen Kanal mit den gleichen Interessen (OP_READ /OP_WRITE etc) mit dem selector Instanzen. Die Registrierung der gleiche Kanal mit mehreren selector Instanzen könnte dazu führen, ein problem, wo selector1.wählen Sie() verbrauchen kann ein Ereignis, das selector2.wählen Sie() interessieren könnte.

Die Standard-Selektoren auf die meisten Plattformen sind von poll() [oder epoll()] basiert.

Selector.wählen Sie ruft intern die int poll( ListPointer, Nfdsmsgs, Timeout) method.
```
        where the ListPointer structure can then be initialized as follows:

    list.fds[0].fd = file_descriptorA;
    list.fds[0].events = requested_events;
    list.msgs[0].msgid = message_id;
    list.msgs[0].events = requested_events;
```
Sagte, ich würde empfehlen die Verwendung einer einzigen Auswahl-thread, wie erwähnt, in der ROX-RPC-nio-tutorial. NIO-Implementierungen sind Plattform abhängig, und es ist durchaus möglich, dass etwas, was auf einer Plattform funktioniert möglicherweise nicht auf einem anderen. Ich habe gesehen, Probleme in der minor-Versionen zu.
Zum Beispiel, AIX JDK 1.6 SR2 verwendet eine poll () - basierten Auswahl - PollSelectorImpl und den entsprechenden Selektor Anbieter PollSelectorProvider, unser server lief gut. Wenn ich zog nach AIX JDK 1.6 SR5, die eine pollset basierende Schnittstelle optimiert-Selektor (PollSetSelectorImpl), trafen wir Häufig hängt unser server in der select() und socketchannel.schließen(). Ein Grund, den ich sehe, ist, dass wir mehrere Selektoren in unserer Anwendung (im Gegensatz zu den idealen eines Auswahl-Thread-Modell) und die Umsetzung der PollSetSelectorImpl wie beschrieben hier.

InformationsquelleAutor Vijay
3

Wenn Sie haben, um mit dieser single-socket-Verbindung, die Sie haben zu trennen, der Prozess von empfangen und schreiben von Daten von und zum Sender aus der Datenverarbeitung selbst. Sie tun nicht muss delegieren Sie den Kanal. Der Kanal ist wie ein bus. Der bus (der einzige thread, der verwaltet den channel) hat die Daten zu Lesen und zu schreiben, es in eine (thread-safe) input queue-einschließlich der erforderlichen Informationen, so dass Ihre client-thread(s) abholen können die richtigen Datagramm-Paket aus der Warteschlange. Wenn der client thread gerne um Daten zu schreiben, dass die Daten geschrieben, um eine Ausgabe-Warteschlange, die dann gelesen von den TV-thread zum schreiben der Daten auf den Kanal.

Also von einem Konzept der sharing eine Verbindung zwischen den Akteuren über diese Verbindung mit Ihrem unberechenbaren Bearbeitungszeit (das ist der Hauptgrund für die Blöcke), bewegen Sie sich auf ein Konzept der asynchronen Daten Lesen, Daten-Verarbeitung und Daten schreiben. Also, es ist nicht die Zeit für die Verarbeitung, die ist unberechenbar mehr, aber die Zeit, Ihre Daten gelesen oder geschrieben werden. Non-blocking bedeutet, dass der Datenstrom, der möglichst gleichmäßig ist, trotz allem, was die Zeit ist, erforderlich zum verarbeiten der Daten.
- Ich fürchte, ich"m ein wenig verwirrt von Ihrer Antwort. Werden Sie sagen, dass ein Kanal ist an und für sich ein thread, dass ein Kanal ein eigener thread, oder sollte ich das setup und Umfrage der Kanäle in einem separaten thread von den Kunden? Ich könnte nicht klar gewesen in meinem ursprünglichen Beitrag, jedes client-Objekt hätte zwei Steckdosen, und zwei Kanäle für die Kommunikation auf beiden Seiten der Anwendung. Ursprünglich schreiben gelernt sockets in C, ich bin vertraut mit dem Begriff der non-blocking vs. non-blocking und speziell wählte non-blocking, weil eine Voraussetzung für die Multiplex-Kommunikation.
- Das wird heikel, also bitte keine down-votes ... das system Probleme Sumpf der Diskussion - siehe: ibm.com/developerworks/aix/library/au-pollset/index.html, das gibt eine bessere Antwort. Ein Kanal ist nicht dazu ausgelegt, ein Threading-thingamabob: Es ist ausgelegt für den Betrieb in der Programmierung Kontexten, in denen wünscht man sich gute io-threading und Leistung. Die gesamte Ausgabe ist zutiefst getrübt durch Probleme, die beschrieben werden in der Real-Time JSR ... der obige link gibt eine Diskussion der Angelegenheit von Ingenieuren informiert über die Angelegenheit. Ich habe einige frühe Tests, es ist nicht wie es scheint.
InformationsquelleAutor cafebabe

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.