View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005649||CentOS-6||-OTHER||public||2012-04-09 14:46||2012-06-27 14:21|
|Priority||urgent||Severity||major||Reproducibility||unable to reproduce|
|Platform||DELL R510||OS||Centos||OS Version||6.0|
|Target Version||Fixed in Version|
|Summary||0005649: Local loopback interface => closing server stream socket does not generate an error at the connected client stream socket|
|Description|| We have client and server applications that use the local loopback interface for sending data on connected stream sockets. The server application detects a "Connection timed out" error on its connected stream socket therefore the stream socket is closed. The client application never receives a stream socket error that the connection has been closed therefore it waits forever for data from the server. Normal operation would be that the client would receive an error at the stream socket layer. The client would close out its stream socket then try to reconnect with the server.|
We have 2 very similar server applications that listen for specfic UDP messages on 2 different networks. Once the message is received, the message is transmitted to their respective client via the local loopback interface with connected stream sockets. The 2 client applications are the same but different instances that have begin configured to receive a specific type of message.
When the error occurred, both server applications logged a "Connection timed out" error within 3 secs of each other. Both clients never received any indication that their connection had been closed by their respective server.
We have a logging mechanism that would have logged an thrown exception if we had been unable to close the server socket successfully. There wasn't a logged exception there the server socket was closed successfully. There is an entry in the log that we are in the process of disconnecting from the client via a socket close command.
|Steps To Reproduce||I'm in the process of recreating the issue on both Centos 6.0 and Centos 6.2 but have not been successful. We are trying to accelerate the movement of messages on the local loopback interface between the client and server as a method to recreate the issue.|
|Additional Information||We have considered using the stream socket option "SO_KEEPALIVE" but we would be missing data at the client since the message is dropped on the floor by the server if the client is not connected. We feel like this is a system issue since 2 different but very similar server applications experienced the same problem within 3 secs of each other. I am in the process of trying to find detailed kernel implementation of the local loopback interface but I have not been successful.|
|Tags||No tags attached.|
|Please close out this bug report. I discovered that this issue was due to a cockpit error of my own doing.|
|A "cockpit" error? Can you say what this means? I ask because I have an application that behaved just fine on Ubuntu, but now that we have migrated to CentOS (eventually to be deployed professionally to a large North American GNU/Linux vendor's distribution, at our client's request) we are experiencing errors similar to what you described. Our application consists of two processes that communicate over a long-lived TCP localhost stream. At seemingly random intervals, the server process will receive a connection timeout and will close the socket, but the client will not be notified of the closing, and will therefore never attempt to reconnect.|
|The cockpit error => I accidentally flushed the firewall rules & forgot that I had done this. The firewall has a default "DENY" setup for input, output and forward therefore ALL interfaces including the internal interface denied all data transfers.|