# BufferedInputStream.Read wirft SocketException auf gültigem Socket



## Muchinger (12. Jun 2009)

Hallo,

wir haben eine Client Server Anwendung, bei der die Clients über TCP/IP mit dem Server reden. Der Server läuft auf Windows und ist ein C Programm, das eine JVM "hostet" und über JNI mit ihr spricht. Die Client Anfragen kommen durch die Java Sockets über JNI in den C Code.

Der Server wartet auf Client Anfragen mit einem BufferedInputStream.read() wobei der BufferedInputStream vom Socket erhalten wurde via new BufferedInputStream(Socket.getInputStream()).

Wir setzen nun Timeouts auf den Socket mittels Socket.setSoTimeout(). Diese Timeouts benutzen wir als eine Art Timer. D. h. jedes Mal wenn der Timeout abläuft wirft BufferedInputStream.read() eine InterruptedIOException, welche wir abfangen und auf der Datenbank ein bisschen was tun. Anschließen setzen wir den Timeout wieder auf ein bestimmtes Intervall, z. B. 5 Minuten "hören" weiter auf dem Socket mit BufferedInputStream.read().

Das soll aber nicht heißen, dass bei uns die Clients immer nur rum-idlen. Es kann durchaus viel Verkehr herrschen zwischen diesen Timeouts. 

Dieser Mechanismus arbeitet einwandfrei bei Hunderten Installationen. Aber es gibt da 2-3 Kunden, wo es leider nicht so läuft. Grundsätzlich liegt das Problem darin, dass nach dem Timeout auf dem Socket und Setzen des erneuten Timeouts das nächste BufferedInputStream.read() mit einer SocketException ("Connection reset") fehlschlägt, statt dass der read() einfach blockiert bis der nächste Request vom Client kommt.

Jetzt kommt es aber noch besser. Das oben Beschriebene passiert nur, wenn sich ein Client von remote verbindet. Ein Client, der auf der selben Maschine wie der Server installiert ist, zeigt dieses Verhalten nicht. 

Ist das dein Netzwerk (Konfigurations) Problem?

Jeder Input ist willkommen. 

Danke und Gruß
Michael


----------



## Murray (12. Jun 2009)

Kann es sein, dass bei den betroffenen Clients ein Proxy dazwischen hängt?


----------



## Muchinger (12. Jun 2009)

Bitte entschuldige meine Ignoranz, aber ein Proxy bei TCP/IP Verkehr im LAN? Gibt es denn so was? 
Denke jedenfalls nicht, dass dies der Fall ist


----------



## madboy (12. Jun 2009)

Einfach mal so ins Blaue geraten: setzen alle Kunden (speziell die mit Problemen) das selbe Betriebssystem und eine JVM vom selben Hersteller ein? Falls nicht, könnte dort (BS oder JVM) ein Bug sein...


----------



## Muchinger (12. Jun 2009)

Wir liefern die JVM mit unserem Produkt mit aus. Betriebssystem ist nicht bei allen Kunden das selbe aber wir haben zumindest 2-3 Windows Versionen, die wir unterstützen.
Aber im Detail weiß man nie, was der Kunde alles so installiert hat und was worauf einen Einfluss hat.

Bei einem anderen Kunden, der das selbe Problem hatte, wurde die Geschichte dadurch gelöst, dass unsere Server Software neu installiert wurde ???:L
Aber bei diesem Kunden hat das leider nichts gebracht ;(


----------



## Murray (12. Jun 2009)

Muchinger hat gesagt.:


> Bitte entschuldige meine Ignoranz, aber ein Proxy bei TCP/IP Verkehr im LAN? Gibt es denn so was?


Klar kann es das geben (hängt natürlich etwas von der Definition von "Proxy" ab; ein klassisches HTTP-Proxy spielt in Deinem Szenario wohl nicht mit, ein _Circuit Level Proxy_ schon).
Aber egal: wie der Vorposter schon erwähnte: finde raus, was die betroffenen Clients gemeinsam haben (OS, Netwerkkonfiguration), und Du wirst dem Fehler auf die Spur kommen.


----------



## Muchinger (13. Jun 2009)

Kann es denn sein, dass eine Komponente, die im Netzwerk zwischen dem Client Computer und dem Server Computer hängt, die Socketverbindung löst wenn ein Timeout auf dem Server Socket erfolgt? Ich denke dabei z. B. an eine Router, Bridge oder Switch.
Wenn ja, wie finde ich das denn raus?


----------



## Muchinger (15. Jun 2009)

Hallo,

mittlerweile bin ich beim Kunden vor Ort und ein wenig schlauer. Ich habe mal verschiedene Versionen der JRE/JVM ausprobiert. Hier das Resultat:
1.4.12  -  alles geht gut
1.6.04  -  beschriebener Fehler ist sichtbar
1.5.11  -  nicht sicher, kann wegen einer anderen Geschichte fehlgeschlagen sein.

Es sieht so aus, als wäre das Ganze ein Problem der JRE/JVM in Kombination mit der Umgebung beim Kunden.
Diese setzen zwischen Client und Server-Rechner einen "logischen Router" vom Typ CISCO 6500 ein.

Kann jemand damit was anfangen?


----------

