it is very strange that the a Timed out Exception was thrown.It wasn't. You didn't get a read timeout. That would have been a SocketTimeoutException. Instead you got a SocketException with a message: 'Connection timed out', which would normally be associated with a ConnectException.
why the socket would buffer the exception?It didn't buffer the exception. It buffered the data that was written. The error doesn't occur until that data has failed to be written, which happens asynchronously after the write method returns and the kernel's internal TCP timers and retry counts have expired, so it can't be reported as an exception immediately.
thanks. the specific value of kernel's internal TCP timers* is located at /proc/sys/net/ipv4? do you know which one?It's not as simple as 'one'. That's why I said 'timers and retry counts', both plural. There is a retry count, a modeled RTT timer per connection, a retransmit timeout parameter, etc. When TCP has decided the remote peer is dead based on a combination of factors it will put the socket into the error state. Don't start thinking that there is a single thing there that you can just tweak. Write timeouts are caused by problems at the other end, or in the network.
and i am very strange that what causes the Exception "java.net.SocketException: Connection timed out" ?I agree, and I have already said so. It is extremely strange. You should never see that error on an established connection.
if the socket or connection is broken, why not throw: " java.net.SocketException: Connection reset "It does, of course.
or "java.net.SocketException: Broken Pipe", or other exceptions.
Actually, in our case, the socket is not closed using socket.close method, and its timeout value is kept its default value:0 which means infinite limit.As I said above in my first reply, this is irrelevant. The socket timeout is a read timeout. Connection timeouts are specified in java in the connect() method, and in any case they are never infinite: about a minute is both the default and the maximum. But if you weren't doing a connect when you got the connect timeout this is also irrelevant.
The 'connection timed out' often means that IP or Port is occupiedNo it doesn't. It never means that. It means no response was received from the remote peer when connecting. If you weren't connecting this is also irrelevant.
is there any possible that the port of Client socket is occupied because some Pc network configuring policy?Doubly irrelevant. If the port was 'occupied' you wouldn't have got the connection at all.
Or is is possible that the port would be closed automatically because of a long time no received response?An intervening firewall might close the connection after a longish interval of no traffic. Nobody closes ports except the application (and the OS when the application exits).
EJP wrote:The original codes have added the try/catch to the socket or Object*putStream, if there are other exceptions, they would be logged to the log files. the connection used in my application is to a remote host, and both peers are running.
It is so strange that I am wondering whether you are observing it correctly. The only time I've ever seen anything like this was on the first write to a localhost connection when the target wasn't running, and it's about 20 years ago so I have no idea whether current TCP stacks still behave like that. Was there any prior I/O on this connection, or is this the first? And is this connection to the localhost, or a remote host?
Yes, and the message is written to an established connection, and this connection may be still valid, because there are no other exceptions.The 'connection timed out' often means that IP or Port is occupiedNo it doesn't. It never means that. It means no response was received from the remote peer when connecting. If you weren't connecting this is also irrelevant.
An intervening firewall might close the connection after a longish interval of no traffic. Nobody closes ports except the application (and the OS when the application exits).If the connection is closed, why the no other exceptions are detected to notify the application. I think the firewall on the network may be one of the cause. And because the result of a computing task costing little time could be normally responded to the client, I suspect that the cause may be at the environment or network, i can not be sure whether there are routers or firewall PC would drop the messages, or automatically close the transferring port.