Discussion:
PipedOutputStream Write end dead
(zu alt für eine Antwort)
m***@gmail.com
2017-06-27 12:05:14 UTC
Permalink
Hallo auch,

ich arbeite schon etwas länger an einer Applikation, in der eine unbekannte Anzahl an Threads mit einem Consumerthread über PipedOutputStream kommunizieren.
Das klappt soweit auch sehr gut, bis auf einige Ausnahmen.
Ab und an (leider nicht reproduzierbar) bricht das System ab mit der Write end dead Exception.
Der Thematik rund um das Thema broken Pipes ist mir bewusst.
Allerdings hilft mir das, bei meinem derzeitigen Design der Applikation nicht wirklich weiter.
Die Software geht grob umschrieben wie folgt vor:

In Main werden PipedInput- und PipedOutputstreams erstellt. Der Inputstream wird einem Consumer Thread übergeben, der dann startet.
Ein weiterer Thread erhält den Outputstream. Bei diesem Thread handelt es sich um einen Listener, der auf eingehende Daten wartet.
Werden diese empfangen, erstellt der Listener einen neuen verarbeitenden Thread und übergibt diesem den Outputstream.
Dieser gibt bei der Verarbeitung weiter an den Outputstream.
Darüber hinaus ist es jedem verarbeitenden Thread möglich, weitere Threads starten zu lassen (über Timer), neue Instanz des verarbeitenden Threads, also mit Übergabe des Outputstreams.

Nach der allgegenwärtigen Meinung müsste ich im Prinzip am Ende (der run Methode) der verarbeitenden Threadklasse den Stream mit close schließen.
Tue ich dies, schlägt der 2. Aufruf eines verarbeitenden Threads an der nächsten Stelle, wo auf den Stream geschrieben werden soll, fehl, vermutlich weil der Stream geschlossen wurde.

Welche Änderungen an der Vorgehensweise wären hier sinnvoll?
Bisher habe ich nur Beispiele gefunden, wo immer nur ein Producer- und ein Consumer-Thread genutzt wurden, bei mir sind es, wie gesagt, eine unbekannte Anzahl von Threads, die auf den Stream zugreifen müssen.

Danke schon mal im Voraus für eine Antwort.
Joerg Meier
2017-06-28 06:05:49 UTC
Permalink
Post by m***@gmail.com
Welche Änderungen an der Vorgehensweise wären hier sinnvoll?
Bisher habe ich nur Beispiele gefunden, wo immer nur ein Producer- und ein Consumer-Thread genutzt wurden, bei mir sind es, wie gesagt, eine unbekannte Anzahl von Threads, die auf den Stream zugreifen müssen.
Weil das eben auch sehr sinnvoll ist. Waere so etwas in Deinem Design nicht
moeglich ? Ein Producer-Thread, der von einer synchronisierten Queue liest,
und Deine anderen Threads schreiben in die Queue statt direkt auf den
Stream ?

Liebe Gruesse,
Joerg
--
"Immer wieder erstaunlich, wie lächerlich man sich doch machen kann und
sich dabei noch toll finden."
- Hartmut Kraus, 19.3.2017 in de.soc.recht.misc

Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
Stefan Ram
2017-06-29 13:11:50 UTC
Permalink
Post by m***@gmail.com
In Main werden PipedInput- und PipedOutputstreams erstellt.
Der Inputstream wird einem Consumer Thread übergeben, der
dann startet.
Mit diesem Thema kenne ich mich nicht gut aus; aber wäre
es möglich, eine »java.util.concurrent.ConcurrentLinkedQueue«
zu verwenden?

Lesen Sie weiter auf narkive:
Loading...