My java application is facing an intermittent connection problem, and I asked a question at: As per the advice, I started looking at network analysis tools and have this file, a conversation from a wireshark capture, http://www.filedropper.com/abcde I want to understand why the connection reset occurs. Thanks. asked 06 Nov '12, 23:33  Abhijeet Kas... edited 06 Nov '12, 23:51 |
3 Answers:
From what I see there seems to be nothing wrong with the client sending a reset. In frame 4 and 5 you have your POST request -> then in frames 9 and 10 the server responds with 200 OK followed by some stuff including the strings "exception" and "Installation failed". This seems to be all the client needs to know cause after that he fires FIN and RST. Is there something missing in the communication or why are you concerned about the RST? answered 07 Nov '12, 02:27  Landi |
Looks to me like the system 10.240.20.251 closes the connection in packet 14 with a FIN (which would be the "nice" way), but also fires a reset packet right afterwards (which is the not-so-nice way). It is strange that the system does this, and the only reason I can think of is that the application has shut down the port without waiting for the FIN-ACK-FIN-ACK to go through first. Maybe there is a socket timeout parameter that is really low, and maybe you can tell the application somehow to be more patient with the session shutdown. answered 07 Nov '12, 02:28  Jasper ♦♦ |
I don't think, that the capture file is directly related to the Java error message. Reason:
You will get this error message if the client is unable to establish a new connection (connect() call). If you get a timeout for an already open connection, you would get a "read timeout" exception. Your capture file shows an established connection, so I believe the Java error message is not related to the capture file. Maybe the connect exception is "kind of related". As we can see in the capture file, it takes 43 seconds for the server to answer a request. That's pretty long. Maybe the server is simply overloaded and thus it does not answer new connections from your client and that's the reason for the connect exception. The FIN/RST behavior in the capture file is kind of strange and there is nothing useful I can add to what has already been said. BTW: Why is there an "Unknown Source" in your Java stack trace? Usually you should see the modules that caused the exception !??! Conclusion: I believe your server is overloaded (from time to time, or caused by a malformed request) and what you see in the Java stack trace and possibly also in the capture file is the result of the overload situation. Regards answered 07 Nov '12, 14:11  Kurt Knochner ♦ edited 07 Nov '12, 14:14 |
Working on how to put the image up here...
These conversations were colorized Red, probably indicating that connection was terminated prematurely, and I also observed a connection timeout. I believe RST packets are not the standard way of finishing TCP conversation. The complete capture is too big to upload, so I sampled one conversation to check what is happening. My aim is to find what causes the timeout, and RST seems suspicious.
RST packets used to be the way to signal trouble with a connection, but nowadays it is a quite common way to tear down successfull communications...