SDK reports error=-10101

Question

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_BLOB1263418646181    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=163841263418766190    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 · Answer

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 · Answer

Thank you for the info. I will take a look at the network interfaces.

segapeli · Answer

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 · Answer

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 · Answer

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

Centera

Was this post helpful?