Problems with socket timeout and JRE 1.6

[ScarFace 01]

Hi,

Our server is waiting for client requests with one BufferedInputStream.read () where the BufferedInputStream was obtained from the socket via new BufferedInputStream (socket.getInputStream ()). We now set timeout on the socket using Socket.setSoTimeout (). These timeouts, we use as a timer. That is, every time the timeout expires throws BufferedInputStream.read () is a InterruptedIOException which we catch and do a little bit on the database. Connecting we set the timeout back to a certain interval, eg 5 minutes and listen to "continue on the socket with BufferedInputStream.read (). This does not mean, however, that at us, the clients only rum-idling. It can be quite a lot of traffic exist between these timeouts.

This mechanism is working properly at hundreds installations. But there are 2-3 customers where it does not have going on. Basically the problem is that reset after the timeout on the socket and setting the timeout again the next BufferedInputStream.read () with a SocketException ("Connection") fails, instead of the read () just blocks to the next request from the client comes. Now it is still better. The above-described here occurs only when a client connects from remote. A client that is installed on the same machine as the server does not show this behavior. The latest information is that this has not happened with the JVM 1.4, but with 1.6 already. But with respect proposes 1.6 it just to even, with perhaps 1-2% of the installations. I suspect that it is a combination of JRE 1.6 and the network environment.

[RichiRich]

This is really tough.. So the exception is thrown in only one place, look at line 168] of java.net.SocketInputStream.read (byte [, int, int) to which this community from the normal read (called).

if (impl.isConnectionReset ()) ( 
throw new SocketException ("Connection reset"); 
)

The impl is implemented in connection java.net.PlainSocketImpl the State CONNECTION_RESET once set in the available method. Unfortunately, the socketAvailble () method is again that is more purely native debug that may not possible.

int n = 0; 
try ( 
n = socketAvailable (); 
if (n == 0 & & isConnectionResetPending ()) ( 
setConnectionReset (); 
) 
) Catch (Exception exc1 Connection reset) ( 
setConnectionResetPending (); 
try ( 
n = socketAvailable (); 
if (n == 0) ( 
setConnectionReset (); 
) 
) Catch (Exception exc2 Connection reset) ( 
) 
)

[Timothi]

What I can not quite understand is that you can customize the SO_TIMEOUT in between because if one looks in PlainSocketImpl we will just timeout when calling the method takes into account DoConnect (...) then forwarded back to the native socket to connect. I am not sure whether to change the timeout on an already mounted socket still effect ... Otherwise, my guess is definitely a flaw in the network because, according to the analysis point in the JDK, not much going on, the cause comes from the deeper layer, in the worst case, a stupid cable has a small tear, you've just a one time connection to a tested with the notebook and server and then?

[StudyBoy]

Here's what occurs to me so - maybe has something to do with it, maybe not. Between the Socket.read operations occurs on the database Ops, a "time out". So the socket is not read continuously. Under certain network environments that might cause a problem with the client (Connection interrupted?), Which in turn would lead to the named exception? That the problem only occurs during communication to the client could indicate this scenario? Why not open your second Consumer Thread (also a Socket-Listening/Reading-Thread and a working thread, which finished with the database timeouts Ops). It seems to me the idea to communicate during the database Ops lower break to sub-optimal.

[ScarFace 01]

@ Timothi

Otherwise, my guess is definitely a flaw in the network because, according to the analysis point in the JDK, not much going on, the cause comes from the deeper layer, in the worst case, a stupid cable has a small tear, you've just a one time connection to a tested with the notebook and server and then?

Well, it alone can not lie there. For if I in the same customer environment using the JRE 1.4, then everything works fine. If I then switch to the newer 6.1 (just on the server exchange), then the error occurs. So there seems to also have something else in Java to handle the newer version.

[void]

Why not open your second Consumer Thread (also a Socket-Listening/Reading-Thread and a working thread, which timeouts done with the database-Ops)

I had certainly thought of that, to implement our database for a type OP-timer that fires every x minutes, thus independent of the timeouts on sockets. But I hesitate a bit to replace a mechanism that has proven itself a hundred times and, according to Sun's documentation actually 100% seems to be OK. There is, namely, that after a timeout of the socket is still valid. In addition, I would have per client connection an additional timer thread, which in turn will cost resources.

[MindSpace]

Upload your times down the Network Monitor: http://www.microsoft.com/downloads/details.aspx?familyid=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

Start the part to see and draw on the communication between the two IP addresses and port of server and client, and wait until the error occurs, then you would have definitely in the sequence of TCP communications can see if the server or the client is very laborious but I think in your case, you have no other chance.

[Praetor]

Upload your times down the Network Monitor: http://www.microsoft.com/downloads/details.aspx?familyid=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

The whole thing only occurs when a customer on the network specialist, and there is not at all accessible. Then I would just take over a greater escalation of what I want to avoid at the moment. At the moment it looks good out there with Java 1.4. In the long term we need to find a solution. Thanks for the tip anyway. I also tried to use SetKeepAlive, but have brought nothing. :cry:

[MELTRONICS]

How about when you would go to the bottom of the problem. The question is why and who sets the RESET flag. Are tools for it enough (wireshark for example). Without the information here is pretty hopeless.