We have some issue on our production environment. In normal condition, communication between two servers(JBOSS application server and SQL 2005 database server) works perfectly. But In some situation, two servers(JBOSS application server and SQL 2005 database server) can communicate with each other for small data (20 records) but communication fails with slightly large data(1000 records). Once this problem happens we have to restart the machine( the server on which JBOSS application server is deployed) to resolve the problem. Note: After restarting the machine(the server on which JBOSS deployed) communication works perfectly (i.e. even with large data). We are doing wireshark packet capture for this problem. It shows following warning in analysis. 1)4 NOP in Row 2)Zero Window What is meaning of above warning? Can these warnings are related to disconnect problem? Any suggestion to isolate the issue would be great help to us... asked 25 Mar '11, 00:04  Maulin retagged 25 Mar '11, 02:33  packethunter |
2 Answers:
NOPs "No Operation" might not be a problem, they're often used as a keep-alive mechanism to prevent an established session from being terminated (especially if it has to pass a firewall with state timeouts). Zero Window is a problem if it is not a reset packet (which Wireshark should not mark as zero window). The TCP window is a receive buffer that gets filled with packets coming in from the sender. If the OS or the application doesn't process incoming data fast enough the remaining buffer (the window) will become smaller and smaller. If it hits zero the receiver tells the sender that it cannot process any more data until further notice (usually through a "window update", but the sender can also test if he can continue using "window probing"). If you encounter zero window problems you are usually facing an overworked receiving station, it is not a network problem but the receiver is not capable to process incoming data fast enough. You should investigate if you can improve the receivers performance by tuning the hardware, the OS settings or (worst case) the application. answered 25 Mar '11, 01:24  Jasper ♦♦ |
Just to support Jasper's statement - you can use "netstat -an" command (should be available on most of the platforms) and 2nd column should show you nos. of packets that are waiting in Q for processing. You can try to tweak "tcp read buffers" answered 25 Mar '11, 01:32  Vijay Gharge |
