Was verursacht den Rückgabewert false bei der Methode ready() eines BufferedReaders

[ortauq]

Ich habe eine sehr wichtige Frage.
Ich habe einen BufferedReader und der Rückgabewert von ready() ist ab einem unbestimmten Zeitpunkt in meinem Programm immer false.

Welche Ursachen kann das haben? Ich weiß was der Rückgabewert in etwa aussagt, aber ich finde einfach keine Antwort auf die Ursachen-Frage.

Was sind mögliche Ursachen, wenn ready()==false?


Ich kann euch leider nicht meinen Code schicken. Der wäre zu groß.

Aber hier ist meine Initialisierung:


mBufferedReader = new BufferedReader(new InputStreamReader(mSocket.getInputStream()));


Also mein Socket ist noch connected und nicht closed, wenn mein BufferedReader nicht mehr ready ist. Das habe ich bereits überprüft.


Ich bedanke mich jetzt schon für Ursachen-Vorschläge.

 

[Chloroplast]

"Tells whether this stream is ready to be read. A buffered character stream is ready if the buffer is not empty, or if the underlying character stream is ready. " BufferedReader (Java Platform SE 6)

ich gehe mal davon aus, dass im buffer einfach nichts mehr ist, also an der gegenstelle nichts mehr gesendet wird (oder nicht schnell genug), das würde ich doch mal überprüfen
LG Chloroplast

 

[ortauq]

Ja, so wie sich das anhört ist er wohl wirklich leer.

Kann noch etwas anderes eine Entleerung des Buffers verursachen, außer durch ein read()/readline() etc.?

 

[Sen-Mithrarin]

vielleicht wäre die erklärung des returns besser gewesen

True if the next read() is guaranteed not to block for input, false otherwise. Note that returning false does not guarantee that the next read will block.

Reader.ready() sagt also aus ob der nächste call von read() blockieren wird oder nicht ...
oder besser gesagt : lediglich ob der nächste call von read() definitiv nicht blockieren wird
anders ausgedrückt : wenn Reader.ready() true liefert kann man sicher sein das man read() call kann ohne das er blockierend auf weitere daten warten muss
umgekehrt ist es aber nicht garantiert das wenn false kommt read() das nächste mal blockieren wird

der sinn von ready() ist mir erlich gesagt noch nicht wirklich klar ... entweder man wartet eben auf informationen und call direkt read() und kümmert sich nicht darum was ready() liefert ... oder man baut sich einen loop der (wenn nicht korrekt aufgebaut) die cpu unnütz mit immer wieder der gleichen abfrage sinnlos auslastet (hier ist auf jeden fall Thread.sleep() erforderlich um auch andere threads dran kommen zu lassen)

ansonsten bin ich gern für wirklich sinnvolle hinweise wo man ready() nutzen kann/sollte gerne offen

 

[ortauq]

Ich habe jetzt eine etwas andere Theorie.

Ich erzeuge immer wieder einen neuen BufferedReader.
Den zuvor erzeugten BufferedReader schließe ich vorher, setze ihn auf null.

Also es gibt keine Referenz mehr auf den zuvor erzeugten BufferedReader.
Dann erzeuge ich einen neuen.

Dieses neue erzeugen funktioniert 1-3 Mal, dann habe ich ein blockierendes read() (Zum testen habe ich vor dem read() das ready() abgefragt).

Gibt es denn eine Beschränkung von erzeugbaren BufferedReader?

 

[Sen-Mithrarin]

ah .. also wohl doch mal wieder so n typischer anfänger fehler

1) hole dir EINMAL vom Socket den Stream
2) packe diesen EINMAL in einen (Buffered)Reader
3) arbeite immer nur mit diesem EINEM Reader
4) nutze close() immer erst AM ENDE der kompletten verbindung > denn close() wird immer weiter gegeben bis es implementiert wird ... oder im fall eines SocketStreams durch eine native methode verarbeitet wird

grund : jedes mal wenn du den Stream in eine neue Klasse packst ziehen diese die daten erstmal raus bis ihr eigener buffer gefüllt ist ... lesen also erstmal den stream leer ...
dann machst du noch einen fatalen fehler : close()
so bald du close() auf irgendeinen stream aufrufst wird dieser ohne rückfrage geschlossen ... und dann auch nicht nur die aktuelle instanz sondern durch alle instanzen die noch dazwischen hängen bis es "ganz unten" dann aufläuft und den stream dicht macht

das du danach dann überhaupt noch ready() und read() call kannst ohne eine IOException zu bekommen weil der stream schon geschlossen wurde ... keine ahnung was dein code da macht ... dürfte aber eigentlich gar nicht funktionieren

und das "wegwerfen" der instanzen sorgt dann noch dafür das die vom stream gelesenen aber noch nicht verarbeiteten daten im nirgendwo landen



poste mal bitte deinen code ... ich denke das da noch ganz andere fehler drin sind die zu noch weiteren problemen führen werden ...

 

[ortauq]

Es würde zu lange dauern diesen code zusammenzukürzen.
Ich kann dir wirklich nur eine Beschreibung geben.
Aber hier noch einmal ganz ausführlich:


Eine GUI besitzt einen start und einen Stop-Button.
Bei einem Klick auf Start wird ein Thread erzeugt.
Dieser Thread erzeugt einen Socket. Daraus gewinne ich einen PrintWriter und einen BufferedReader.
Diese beiden dienen zur Kommunikation.

Bei einem Klick auf Stop, wird der Thread beendet und alle Sockets/Reader/Writer werden geschlossen und auf null gesetzt.

Also jeder Thread erzeugt seinen ganz eigenen Socket mit eigenen Reader & Writer. Die gibt es nur lokal in diesem Thread.


Wenn ich start klicke, dann stop und dann wieder start, dann müssten die Reader und Writer völlig unabhängig voneinander sein. Sind sie aber anscheinend nicht.

Ich kann 2-3 Mal start&Stop drücken und alles funktioniert.
Ab dem 3. bzw. 4.Mal lässt läuft die kommunikation mit dem BufferedReader gar nicht mehr.

Ich verstehe das nicht. Die BufferedReader dieser Threads kennen sich in keinster Weise.
Als ob mein Programm sagt: "Du hattest seit dem Programmstart genug Zeit mit dem BufferedReader verbracht. Ab jetzt verweigere ich dir jede Kommunikation über den BufferedReader. Auch wenn es ein ganz neuer BufferedReader ist".

 

[Sen-Mithrarin]

du sollst den code auch nicht kürzen ... da du sonst vermutlich genau die stellen rauskürzt die den fehler verursachen ... du sollst ihn wenn dann schon komplett posten ...


und wenns hier mit dem zeichenlimit nich hinhaut gibt es immer noch Pastebin.com - #1 paste tool since 2002!

ist richtig ... wenn wirklich alles sauber in einzelnen threads läuft ... sollten sich weder die sockets noch die streams letztenendes kennen ... ich vermute du hast irgendwo doch unbewusst noch ne brücke geschlagen die so nicht hingehört ... vielleicht irgendwo was static ...

wie gesagt : ohne (kompletten) code wird es rätzelraten

 

[ortauq]

Ich habe derweil die Sache mit einem sehr kurzem sleep() gelöst.
Weder ich, noch Kollegen verstehen, weswegen das ganze nun funktioniert, aber was solls. Die Millisekunde stört in meiner Anwendung keinen.

Trotzdem danke für eure hilfe ^^

 

[Sen-Mithrarin]

na ... da wird der fehler wohl ganz wo anders liegen ...