As of right now I have a timeout specified for how long a request can take using the .NET client. I am using ExecuteGet to get an IGetOperationResult object returned to me. I need to determine whether or not the ExecuteGet call is taking too long and exceeding my timeout.
What exactly would the combination of expected IGetOperationResult values be? I suspect a null StatusCode and an exception in Exception. Is this a correct assumption? What type of exception would I be expecting? If not, I noticed the InnerResult field that some lines talk about some problems being reported there but would this be one of those cases?
The Java documentation directly addresses this here stating:
When this timeout occurs, most of the synchronous methods on the client will return a RuntimeException showing a timeout as the root cause. Since the asynchronous operations give finer grained control over how long is given for an operation to be successful or unsuccessful, this path throws a checked TimeoutException.
What about .NET? Current client is v1.1.6 if the Windows property window is to be believed.
@tgrall update is not an option. This is a non trivial system and this requirement would be required to be filled prior to the time that would take to validate and QA the version change plus any code changes that would be required.
I also see unknown get failures periodically in a high-load production system. I’m using server 2.0.1 on CentOS, and using the 1.2.4 .NET SDK. I see this problem maybe once per week, so it is fairly rare. I’m using ExecuteGet, and the IGetOperationResult indicates Success==false, but no other information is provided. No message, status code, or exception, and no InnerResult either. My logs aren’t currently revealing whether this is a timeout or not, but I plan to instrument my API wrapper to provide timing metrics to make it easier to determine if these are indeed timeouts, or perhaps some other type of transient network failure, which is also possible.
So this is a bug in earlier versions of the SDK that have been resolved in 1.2.9, and I highly suggest you update to it ASAP.
That being said, typically when the message is empty and the StatusCode it means that a client error has occurred - this could because of a timeout with respect to resource contention (too many threads and too few available sockets). Almost always this causes a timeout, thus in that client version you can assume that you have timed out.
Note that starting with 1.2.9 client timeout errors are properly returned as 145 (or 0x091 in the Enyim.StatusCode enumeration).