Unsolved
This post is more than 5 years old
1 Rookie
•
8 Posts
0
3775
January 22nd, 2010 12:00
SDK reports error=-10101
Hi,
I am seeing the SOCKET Error ( -10101) from an SDK trace during a write operation. I know this could mean all sorts of network issues, however I only see this when the SDK is used on an HP/UX system . When the SDK is used from an AIX or Windows system within the same environment (same data and network ) the store operations work fine. The SDK trace however shows that the SDK that appears to stall for exactly two minutes. See the timestamps in the trace below:
1263418646181 2010-01-13 21:37:26.181 [debug] 6275.77 [TRANSACTION] Export Data albert/125/WRITE_BLOB
1263418646181 2010-01-13 21:37:26.181 [debug] 6275.77 [PACKET] send SmartPacket
NET_SYSTEMID type=string value=albert
NET_TRANSACTIONID type=string value=albert/125/WRITE_BLOB
NET_VERSION type=integer value=3 HPP_CLIENT_VERSION type=integer value=197124 NET_MESSAGEID type=integer value=42 HPP_VERSION type=integer value=1 HPP_CONTROL type=integer value=0 HPP_OFFSET type=long value=1441792 HPP_SEGDATA type=bytearray value=16384
1263418766190 2010-01-13 21:39:26.190 [debug] 6275.77 [EXCEPTION] In 'Connection.cpp' at line 556: Exception
error=-10101
syserror=0
message=send: waitForWritingData(120000) returned zero
trace=No trace available
The SDK API Reference states that the default timeout for idle connections is two minutes so I am assuming that this socket error is simply a connection time out. But what is the SDK doing in between these two trace statements for two minutes?
The error is intermittent.
Thanks.
gstuartemc
2 Intern
•
417 Posts
1
January 22nd, 2010 12:00
The SDK is doing nothing - it is waiting on the results of the HPP transaction coming back. In your case, this is timing out because it is not receiving the response within the 2 minute timeout period.
I have encountered numerous similar issues with HP-UX servers in the past. It could be something in the way that the device drivers are written or something odd in the NIC cards that are used by HP.
Ensure that the duplex settings match up with those of the cluster - a mismatch can often cause problems like this. Next step is to try changing the actual NIC card or moving the host to be on the same physically connect network segment as the cluster (if possible).
segapeli
1 Rookie
•
8 Posts
0
January 22nd, 2010 14:00
segapeli
1 Rookie
•
8 Posts
0
January 25th, 2010 13:00
Hi,
Do you happen to know if there is a best practices guide relating to Centera and network configurations - specifially concerning HP?
Thanks,
Mike
gstuartemc
2 Intern
•
417 Posts
0
January 26th, 2010 05:00
Hi Mike - the only other thing I would suggest would be to have the buffer size for the NIC card set to match what the SDK uses i.e. 16KB. The SDK default values match the "best practices" for communication with the Centera.
segapeli
1 Rookie
•
8 Posts
0
January 29th, 2010 13:00
Hi Graham,
We noticed that our network interfaces on our access nodes were all set to 100MB. The rest of our lab is mostly Gig ethernet. So we reconfigured the interfaces on the Centera for Gigabit and the errors went away. Also the stores are way faster.
Thanks for your help
Mike