Java-Sockets: Kein Pufferspeicher verfügbar (maximale verbindungen erreicht?)

Ich habe ein großes problem. Ich entwickelte eine client-server-Anwendung. Ein client-thread sendet ein serialisiertes Objekt auf dem server und der server sendet ein serialisiertes Objekt. Derzeit bin ich mit ein server und 10 client-threads und nach etwa 30 Sekunden bekomme ich die Fehlermeldung von jeder client-thread (IOException):

Kein Pufferspeicher verfügbar (maximale verbindungen erreicht?): verbinden

Wenn ich mich in netstat dann sehe ich, dass es eine Menge von verbindungen erstellt, und es wächst und wächst und alle verbindungen sind in TIME_WAIT Zustand.

Ich weiß nicht, warum. Ich schließen der sockets im server und in den clients immer in einen finally-block. Hier einige code:

In der server habe ich in socketHandlerThread:

ServerSocket serverSocket = new ServerSocket(port);
serverSocket.setSoTimeout(5000);
while(true) {
       Socket socket = serverSocket.accept();
}

Die neue Fassung wird dann auf einer LinkedBlockingQueue und ein worker-thread nimmt die Steckdose und macht die folgenden:

try {
      outputStream = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));
      outputStream.flush();
      inStream = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
      ClientRequest clientRequest = (ClientRequest) inStream.readObject();
...
      outputStream.writeObject(serverResponse);
      outputStream.flush();
} catch....
} finally {
                if (inStream != null) {
                    inStream.close();
                }
                if (outputStream != null) {
                    outputStream.close();
                }
                if (socket != null) {
                    socket.close();
                }
}

Auf der client-Seite habe ich folgenden code:

    try {
        socket = new Socket(host, port);
        outputStream = new ObjectOutputStream(new BufferedOutputStream(socket.getOutputStream()));
        outputStream.flush();
        inputStream = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
        outputStream.writeObject(request);
        outputStream.flush();
        Object serverResponse = inputStream.readObject();
   } catch....
   } finally {
            if (inputStream != null) {
                inputStream.close();
            }
            if (outputStream != null) {
                outputStream.close();
            }
            if (socket != null) {
                socket.close();
            }
   }

Kann jemand helfen? Ich weiß wirklich nicht, was für Fehler ich gemacht habe. Ich scheint, dass die buchsen bekommen, nicht geschlossen, aber ich weiß nicht, warum.

Könnte es sein, das problem, dass ich die sockets in eine Warteschlange auf dem server-Seite, so dass die Buchse irgendwie kopiert?

Edit: Wenn ich dem client und dem server jeweils auf einem anderen Amazon EC2-classic-Instanz mit Linux AMI, dann funktioniert es. Könnte es ein problem mit Windows oder ist das problem einfach, dass ich mit den Clients und dem Server auf der gleichen Maschine (mein lokaler pc)?

Nicht jemand sieht einen Fehler in meinem code?

Edit2: Wie oben schon gesagt, auf EC2-Instanzen funktioniert es aber wenn ich netstat zeigt es immer noch eine Menge von Linien, die sagen TIME_WAIT.

Hier sind screenshots:

https://drive.google.com/file/d/0BzERdJrwWrNCWjhReGhpR2FBMUU/view?usp=sharing

https://drive.google.com/file/d/0BzERdJrwWrNCOG1TWGo5YmxlaTg/view?usp=sharing

Erste screenshot ist von windows. "WARTEND" bedeutet "WARTEN" (es ist Deutsch).

Der zweite screenshot ist von Amazon EC2 (auf der linken Seite der client-Rechner, rechts der server-Maschine).

Nur ein Gedanke-warum nicht, RMI? RMI übernimmt die socket-thread-Problem.
Ich habe mit diesem Stil leider.
Was sagt netstat wirklich sagen? 'Waiting' ist nicht ein port state.
Ich aktualisiert meine Frage
Aber Sie haben nicht beantwortet meine. netstat kann drucken Sie ein Dutzend oder so Staaten, aber 'Warten' ist nicht einer von Ihnen. Es gibt mehrere mit _WAIT im Namen. Welche ist es?
Welchen Befehl muss ich setzen? Einfach nur zu schreiben "netstat" in die Kommando-Konsole? Oder mit ein paar Argumenten?
Ich Frage Sie, was Sie schon gedruckt. Wenn Sie nicht wissen, wie Sie laufen ich sehe nicht, wie Sie möglicherweise können Sie behaupten, dass es nicht gedruckt überhaupt nichts. Sie könnten versuchen netstat -anp tcp zu bekommen-Ausgabe nur für TCP, aber bitte melden Sie es genau. Fügen Sie eine Zeile oder zwei der seinen Ausgang in der Frage.
Sie versuchen, zu viele verbindungen zu schnell und läuft die lokalen ports. Wenn, dann aufgrund eines Fehlers, den Fehler beheben. (Warum nicht Sie verbindungen wiederverwenden?!) Wenn Sie wirklich versuchen, so viele verbindungen, die Sie benötigen zu fangen, in diesem Fall warten Sie etwas, und versuchen Sie es erneut.
Können Sie versuchen, was passiert, wenn auf der server-Seite setzen Sie in einer Thread.sleep(3000); bevor Sie beginnen, schließen Sie die Buchse?
Ich habe ein paar screenshots Hinzugefügt

InformationsquelleAutor machinery | 2014-10-16

3

ZEIT-WARTEN ist eingetragen nach wird die Verbindung an beiden enden geschlossen. Es dauert ein paar Minuten, für die Integrität der Daten Gründen.

Wenn die Puffer-problem ist aufgrund von ZEIT-WAIT-states auf dem server, die Lösung ist, den server werden nach dem peer, der erste empfängt der Nähe. Das wird shift die TIME-WAIT-Zustand an den client, wo ist es harmlos.

Können Sie tun, indem Sie Ihre server-side-request-Verarbeitung in einer Schleife, so dass es in der Lage mehrere requests pro Verbindung, und so, dass der server nur schließt das socket, wenn er erreicht das Ende des Stroms auf.
```
for (;;)
{
    try
    {
        ClientRequest clientRequest = (ClientRequest) inStream.readObject();
        ...
        outputStream.writeObject(serverResponse);
        outputStream.flush();
    }
    catch (EOFException exc)
    {
        break;
    }
}
```
Wenn Sie dann umzusetzen connection-pooling auf dem client, Sie wird Massiv reduzieren die Anzahl der verbindungen, für die weitere Verringerung der Inzidenz der Puffer-problem.
- Und Ihr problem auf der deutschen Windows-Maschine ist, dass Sie die server und den client auf dem gleichen host, und erstellen Sie Myriaden von verbindungen, die nicht einer realistischen test.
- Ein client stellt eine Verbindung zum server und nach bekam er die Antwort, er schließt die Verbindung. Dann wird eine neue Verbindung hergestellt wird und so weiter.... So, ich habe eine Menge von verbindungen. Ihre Lösung ist gut, aber ich bin nicht erlaubt, dies zu ändern (kein connection-pooling). Jedenfalls sollte der server noch warten ein Ende-stream und dann schließen? Er erhält nur ein Objekt. Und kann der Zeit-Weise nicht reduziert werden auf 1 Sekunde oder weniger? Warum ist der time-wait-Zustand gutartige am client? Wenn ich zu viel Zeit wartet auf den client, der client kann neue verbindungen erstellen.
- Sollten Sie dennoch implementieren Sie die Schleife an den server, der Grund, warum ich erwähnt. TIME_WAIT gutartige an den client, weil es nicht multipliziert mit der Anzahl der Kunden, wie es auf dem server: es gilt nur für die client-verbindungen. Sie sollten auf jeden Fall implementieren, connection-pooling, als auch, wenn Sie wirklich wollen, um dieses problem zu lösen, und Sie sollten, so raten jedem, der denkt, dass Sie aufhören sollten, Sie.
- Vielen Dank, aber ich weiß nicht genau, was du meinst mit der Schlaufe an den server. Könnten Sie einige kleine Beispiel-code? Die clients senden nur ein Objekt, sendet der server eine Antwort, aber und schließt die Verbindung. Also ich habe nicht mehrere requests pro Verbindung.
- Aber Sie sollten den code Ihrer server, als ob Sie das tun, dass ist der Punkt. Einfach eine Schleife um das request/response-handler, der beendet ist, wenn EOFException gefangen ist.
- Ok, ich hab dein code-Beispiel. Ich danke Ihnen sehr. Aber... in der ersten iteration ist es, ein Objekt zu Lesen und einen zu schreiben, also alles ok. Aber in der zweiten iteration wird der block an der instream.readObject.
- Nein. Wie ich schon sagte, es wird beendet, wenn EOFException gefangen ist. Das passiert, wenn der client die Verbindung schließt. Oder, Wann und ob Sie sich vorstellen Verbindungs-pooling, wird es mehr Anfragen. Sie können immer versuchen Sie es, anstatt nur zu raten.
- Ich werde gehen mit Ihrer Lösung von einem connection pool. 😉 Ich werde zu öffnen, ein follow-up thread auf stackoverflow für dieses problem.
- Nur eine kurze Letzte Frage. Ist die Reihenfolge des Schließens der inputStream, Ausgabestrom und socket im client und server in meinem obigen code ok?
- Ist es möglich, die Zeit zu reduzieren-warten auf Linux, sage 1s? Oder kann ich SO_REUSEADDR?
- Looping auf dem server von entscheidender Bedeutung. Verbindungs-pooling ist wünschenswert. Sie sind nicht die gleiche Sache. Sie sollte in der Nähe der stream-Ausgabe, dann die Buchse I n einem finally-block für das schließen. Es ist nicht notwendig, schließen Sie die input-stream als auch, und es ist nur notwendig, um in der Nähe der Steckdose, wenn das schließen der output-stream fehlgeschlagen ist. Es ist weder möglich noch wünschenswert zu reduzieren TIME-WAIT zu einer Sekunde. Es ist ein wichtiger Teil der TCP die Integrität der Daten. SO_REUSEADDR lösen nicht ein Puffer Erschöpfung problem.
- In meinem code, wie Sie oben sehen können, habe ich geschlossen, die in den finally-block der inputStream, den Ausgabestrom und die Buchse in der Sequenz. Ist dies die Ursache für meine Probleme oder sollte diese noch funktionieren?
- Es ist nicht die Ursache des Problems. Es ist nur der richtige Weg, es zu tun.
InformationsquelleAutor user207421

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.