X-Received: by 10.157.40.79 with SMTP id h15mr2875839otd.123.1498565114511; Tue, 27 Jun 2017 05:05:14 -0700 (PDT) X-Received: by 10.157.3.34 with SMTP id 31mr102182otv.14.1498565114483; Tue, 27 Jun 2017 05:05:14 -0700 (PDT) Path: csiph.com!feeder.erje.net!2.us.feeder.erje.net!weretis.net!feeder6.news.weretis.net!news.glorb.com!185no1657854itv.0!news-out.google.com!k7ni1281itk.0!nntp.google.com!185no1657851itv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: de.comp.lang.java Date: Tue, 27 Jun 2017 05:05:14 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2003:ce:1bca:7d00:e0b7:b8c6:60e:dbfb; posting-account=uDcqFQoAAAD8catZ9YgcM3YaeqwF8Qnl NNTP-Posting-Host: 2003:ce:1bca:7d00:e0b7:b8c6:60e:dbfb User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: PipedOutputStream Write end dead From: marcell.thissen@gmail.com Injection-Date: Tue, 27 Jun 2017 12:05:14 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: csiph.com de.comp.lang.java:13120 Hallo auch, ich arbeite schon etwas l=C3=A4nger an einer Applikation, in der eine unbek= annte Anzahl an Threads mit einem Consumerthread =C3=BCber PipedOutputStrea= m 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 nic= ht wirklich weiter. Die Software geht grob umschrieben wie folgt vor: In Main werden PipedInput- und PipedOutputstreams erstellt. Der Inputstream= wird einem Consumer Thread =C3=BCbergeben, der dann startet. Ein weiterer Thread erh=C3=A4lt 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 Th= read und =C3=BCbergibt diesem den Outputstream. Dieser gibt bei der Verarbeitung weiter an den Outputstream. Dar=C3=BCber hinaus ist es jedem verarbeitenden Thread m=C3=B6glich, weiter= e Threads starten zu lassen (=C3=BCber Timer), neue Instanz des verarbeiten= den Threads, also mit =C3=9Cbergabe des Outputstreams. Nach der allgegenw=C3=A4rtigen Meinung m=C3=BCsste ich im Prinzip am Ende (= der run Methode) der verarbeitenden Threadklasse den Stream mit close schli= e=C3=9Fen. Tue ich dies, schl=C3=A4gt der 2. Aufruf eines verarbeitenden Threads an de= r n=C3=A4chsten Stelle, wo auf den Stream geschrieben werden soll, fehl, ve= rmutlich weil der Stream geschlossen wurde. Welche =C3=84nderungen an der Vorgehensweise w=C3=A4ren 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 unbekannt= e Anzahl von Threads, die auf den Stream zugreifen m=C3=BCssen. Danke schon mal im Voraus f=C3=BCr eine Antwort.