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
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
